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ABSTRACT ' . • • . v 



,The Siiaolation and .Gaming Project for Inter-Institutional 
Computer .Netwarking is a joint effart on the part of EDUCOM and 
eighteen participating institutions to investigate the role 
.that computing networks -miglit 'play in* higher education: and 
research. Central to th^ project is the development of a'^ 
-computer srnulation model of. a possible^ national ifetwork, 
composed x)f the participatin/^ insti-tutions ^ in which se^rvices - 
can be exchanged through a market medium. 

ihis is ^ Teport on t)ie results o-f^ the '^ir^t year of the 
» . ' * • 

-^ree year study. , Included in this phase 'were the. develop^ient.^ 
of representational' concepts , the design and implementation of 
the Ibasic simulation model, the cofiection of- data fromHfie 
participating institutions , and Ae conduct of some , preliminary 

experiments using tht model, • ^ 

« Later emphasis will be on Using the model for a comprehensive 

investigation into 'the organizational 4niplications of a network, 

the conditions necessary for a successful network, and the likely ' 
problem areas that must 'b.e monitored. 



I.- EXECUTIVE 



A. • Introduction . . ' • 

r • • 

Among^the most dif f icult ttfuestiohs confronting decision 
makers at college^, universities and research institutions arB 
those concerning the brest manner of satisfying the expanding 

. and increasingly', varied demands for coslputing services^,. The 
Vast increase in computer use now imposes serious '^in^jacial 
burdens on many educational institutions, necessitating that 
th.ey seek more effi.cie^t* and effective ways of providing needed 
cajfabilitifes* ^ * . 

, ' * . . 

f---^' One, of the- most'^promisdng Seans of accomplishing this goal* 
is that bf sharing ct5mputer resources thrc?ligh a^^inational computer 
network*'^ Sharing .is .not just a matter of economy, but it can 
open up^ ne^ possibilities to tha educational and research commu- 
nity, it har§ the potential to offer to all dnstitutiojis through- 
^out the countjry the best coEapu1;^ing resources available --'a 
variety ^nd tjuiMt^ of resources which not even the largest .single 
institution could Hope to provide on its* own*. ' 

• * ' - 

There is' very little doybt that such sharing will take place|, 
since it already -exists in at least 9 relatively primitive form. 
However, the extent and form of the sharing will depend on many 
complex organizational, economic, and behavioral issues.. Even 

if a network only f-ocuses on the needs of higher education, a ' 

- c ' ' 

lar^e Hiimber of alternative .arrangements are^ possible, .For. 

• )eXample, the degree of centralization of the network, pricing 
schemes,, and budgeting procedures at each ^university ail^ introduce 
possible variation^.. An institution's policies witlj respect to ^ 
outside ^purchases ; and- its willingness to assume the 'risk "Caiwi 
gaixi.the benefits) of developing the resources required to iecome 

^^a network supplier, will 3l1so affect the network, behavior'. 
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Network arrangements ^nd institutional policies' interact { 
itt complex^ways. It is not possible, .the;re£ore', to. make reliable 
a priori predictions about the. co.ns€!quences of the many possible 
combinations, of alteiyiative decisions, this is true of macro* 
decisions tllat affect the entire network, < as veli ,as at the.micro^ 
level of aiL individual institution or an individixal user. 

It is extreiaely diff-icfult to experiment with a functioning 
network, except Ia only minor incrementjal >ays. * Analytical modeis, 
while useful in providing insights into network phenomena > caiinot; 
begin to capture^ the full richness of possible behavior that would 
interest network designers aad institutional policy makers . Of 
the tools available, then, only simulation techniques permit in- 
vestigation of th^full range of ^^altj^rnafives. that must be con- 
sidered. ' * ' ■ • * — 

B. - Development of the Ne.twort: Simulation and Gaming Model y 

the cjLirrei)t simulation project grew out of ^. six-month^ 

planning study funded by the National ^cience Foundation (NJSF) . » 

A, group of eight "cox>perating investigators representing 

a wide variety -of academic ba.ckgrounds , planned and recommended 

sup|)ort of a major effprt to investigate the role that computing n^t 

works might play in higher education. The group felt' that a ' ^ 

f • 

simulation model would be a necessary tool of such an investigation. 
EDUCOM submitted a proposal to perform the study, and in February, 
1975 it was approved by, NSF.r 

The project extends over a ^three-year period. This first 
phase encompassed many areas including the development -of reppe- * 
sentational concepts, the design and . imglementation of the basic>-- 
simulation model, and the conduct of ini«al experiments. It 
alsd^ included the collection of data from 16 educati oiial and re- 
seai^ch institutions that are^ajticipating in thp network 'experi- 
ments. The collected data describe — albeit., in relatively pre- 
^lim^n^ry form — each institution's present demand for, and supply 
..of, computing services. Collectively the 16 institutions constitute 



a possibj-e network in which, services .can be exchanged through 
a market meQhanism^>- , - ' - 



The seconds phas^ of the proj^ect, which has already, begun, 
will concentrate on obtaining a deeper understanding o^ each parti- 
cipating institution's facilities/ computing demands, and policies 
'affecting its network activities. The results of ''theSe studies 
will be re^l'^cted in refinements to th? model so that it can more 
faithfully represent the specific behavior of each site on the 
network. It will then be used to examine the effect of a variety 
oi behavioral, decision, and policy patterns on hetworks and. in- 
sfit'utio.nal membei-s. ^ ^ ^ ' ^ . 

The filial phase calls •fdT -a modification of tlTe* model- to per- 
mit human decisis^n makers tQ inputs decisions interactively dicing 
# • ' » ... ' t * 

a simulation run. In the current Phasfe I version of the model,' 

decisions are made automatically by the model based on built-in 
policy rules, • In the "gaming'* version, administrators at the parti- 
cipating institutions will be able to modify, decisions at any point 
in simulated- time . In this wav an . administrator can make ad hoc 
decisix)ns in any arbitrary way, rather than being forced to define' 
a rule that remains in effect- thrdugKout 'the simulated run. Thus 
the gaming phase will introduce a reality^to the model, that could 
not be achieved solely with pre-defined rules. 

C. Characteristics of the Simulation Model ' . * 

Although construction of the. simulation model is only bne part 
of the overfill project-, it is a vital part, .The model proff'ides an 
essential t-^l for the studies that constitute the real justifica- 
tion for the* project , , ^ ' ^ . 

The model was constructed in- a modular, top-down fashion. Thi6, 
has permit^ted tfest^ng of its higher-level comp'oneijts as developmejit * 
work proceeded. This approach also offers the tremendous, advantage 
of flexibility: iower-Level modules can 4)e added or modified jKithoiif 
aFfecting other modul'es or the overall structure of the- model^ This 



is zfi absolutely necessai^^ requirement J[or a model that^^will under- 
go continual eyolutroniiry development over the life of thfe project. 

♦ / *' • . - , - 

^ Wheii the model is run, time moves forward in' fixed weekly 

increments. Durijig each weekly calculation, desiand for computing' 
^services is g«riex>^ted according to the b'uilt-ih rules 4o^, during 
the gaming, phase, to. any ad hoc changfes made by, a huDfanydeclsion ^ 
maker), . The rules take. into account policy* decisions and the status^ 
of the network during the previous weekly time interval (e.g.,* 
response time at each compfuteY center, cest ct each s,ervice, etc.). 
The aggregate demand placed on a given site depends on the demand 
tiJroughout the network, polity constraints on network purchases, 
'physical constraints on cpmmunications capacity, and, the attractive- 
ness of * the site relative to othjer sources of supply (intluding, of 
course, a user's own local computer center). 

Time moves forward week-by-week in this fashion. Demand and 
"Stipply at each ins^f ituticfn and the flow of services among center^ 
sKift dynamically a^ simulated events unfold. Periodic rei^orts and 
^ final summary report-s are produced to describe shifting supply and 
demand levels, the f loW^^of work, and^ selected financial variables 
at each institution. , < ' ' ' , 

♦ ' ' ^ t * 

The model is written in FORTRAN to make it Bs transportable as 
possible. Special dare has also been given to careful documentation 
to increase the model's transportability. Participating institu- 
tions, as well ajs the academic and rehear ch,*community at large, will 
b>5 •encouraged ♦to use the model i*n exploring alternative jietworJc 

decisions or organizational arrangements. * ^ / 

, * ' - • 

D. Project Management - ^ ' ~ - 



The mod^l is large enough, and involves a. lajge enough group 
of participants in its development^ that careful attention' had to 
be given to management of the project. From its inception, the 
project 'called for the coordination of researchers di;awn from a 
number of different institutions. This r^^quired cl<fse attention tO' 



' I *" ' ' - ' ' ' - . ' • . . • . 5 ' '' 

^ -dpcximentatifii an(J dissemination of thfi current Studies *o,^ the , 
project. ' ■ . , ' •• ^ * . 
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The ^:oT5p€ratiji^ iVivestiga^ors have continued with the praject 
throughQ3*t its life.. .Perio.dic review ^jneetirigs. have, breen heia" to 
critique 'the work done by the EDUCOM staff ind to obtain further 
kdvice for future development work. "^^ . - * 

Retpresenta^^ves from ^11 of tjie participating insti;tutions 
have attended one of ,thr.ee regional meetings that were presented • 
, The purpose of the meetings was to establish personal contact with 
^each institution, to explain Xhte model, .to describe ^data coileclion 
requirements, and to obtain feedback comnieiits from participants; . 

A^number cf special' studies have been commissioned as* an in- 
tegral part of the prpject. One of these focused on. developing a- 
pei:ception of computing, services, that flow across the network. ^- 
Anotiier developed a .model for predicting the impac^on a computer 
cea.ter of shifts in demand for Its services* - Similar studies 
focusing on prograiq benchmarking , network marketing and its effect 
on'demand,, and pricing and , budgeting strategics have been co;n- 
mis^ened and will play^ an important part in enhancing? the value 
of the research. The intent of this apnroach is-to 4^aw upon the 
best resources available to h'elp^in developing the ^od?l ^ while 
'still retaining overall project coordination in the hand*= o-^ the . y 
.EDUCOM ctaf^. / ' . * , ^ 

The* emphasis in *Phase r was on ^he research and background ^ ' 
work n^ecessary-to design and implement the basic model, and on 
the use'of this model to study factors influencing network behavior. 
As a result of the successful completion of. this work in Phase I, , ;^ 
efforts^'Can procjeed with ^the application .of th*e moiei to the ^ore ^ 
interesting Behavioral, organizational and impact issues which . 
will'be examined in Phases IT and III., * . 



* ^ The project is ba><?ically adh^erine to the schedule and budget' 
^ Established in the original proposal. Soflte parts- of the. project 
are pjoceed^ng somewhat faster than expected, whil?' other parts 
^are. proving more diff icult^'and time consuming than planned. For 
examp^Le, the modular cons true titon of the model will reduce the ' 
expected »ef fort required, in Phases tl 'and III to adapt if to " 
individual institulTioh'S aj]d to incorporate interactive modifica- 
tion' of decision rules. ^Data collection, on ^he other. ha^d^ is 
somewhat behind schedule. The expectation is, however, that the 
overall project will.be completed within the j)roposed time and 
budget. " .1 ^ • . » , 



■ ' --11. 7lM0DUCTI0N . ^ - 1'"' ^ 

. ■ i • •• • •• -A. . - '■ .: 

'A. Backgroaind J ' ^ • • 

/ ' ' ^ ' • . • * i , . w ' ^ 

Decision makers .at educational^ and "research, institutions are ^ 

grappling * with difficult questions abput how to best satisfy *the^ • 

exjyending and increaVingly varied demands for ^cqraputing Services. 

It is cle^ar ^that, although usgr.dfemand^ Viil cbntinue ^o grow, - . 

th^ cost spiral must^be controlled/ TechnologJLcal advances in ^ - 

/^icro-. and mini - computers j andv in lar^e, sc^^Jiard^artf facilities, 

will' not,, in theurseiyes, b^suf f icient. t^BBHB^^Lly s.artisfy * ^ 

the.' requirements fo?^ a,ccessit)ility to a g^lRfeT^^jvariety and sd» 

phistication of se'rvice offerings-. * 

Netwo'rks offer one of the mo5t attra«i^i^fe^ossibilities ^ar 
improving thp'^ef f iciency and^ effectitrSness^of c6m^>^ting,}^J / The 

* report of the delibera'tion^ at a NSF-v^ponsored serieVCptf General . 
.Working Seminars on couipliter networking^ ^ held in 1972 aii,d.l973 
JLndica'tgd ^that it is now technically feasible to cr^te a ne%^ork' 

^ l^inking ^research and edutation^ ^computers a^ colleges, univ^rsi- ^ ^ 
ties^'^ and research institutes. Alfhough some technological ptob^ C 

Vlems remain, the^.diff ic;jlties o^Hti^kirig^ these "institutions are . 
/primarily nontechnical in nature. Pst particular , major economic, 

" politfxH/ and ^organizational cans'jderationi are lijcely to pace 
the developmefit of a successful, network. Thes^M^sues caij 'success- 
fuliy be desalt with onj'y on the basis- of a qlear Understanding 't)f 
the potentials, limitations, and implications of networking. 

Existing networks p^^ti^de a good indicatio^n of .thevgosts -and ^ 
technical Ghara<:teristics of a national network*, j i*fw is still pot. 
clear, .however, hq^ a dynamic national ijp^ttJrorking environment 
.would impact a given institution in^term;?. of economic; qrganiza- ; ' 
tionali political, an4 intellectual effects. Wor/is it known .how 
the^e effects would vary A^rth the part^icular computing .phi losi^hy, 
' policies^ and practices In .effect at an institution. For example, ^ 
what changes would a network bring in ins truction;. rese^rch/.science 



iliioi;ination, and aUministii^tj-y^ compu^ng? J^hat 'would, be ,the Im- 
pact of "baldnre of payments^' '^problems? How, woy^id users be- affected 
by thi availability of multiple ''fypes of resources at a yariety \ 
pipLcesTj What chjeihges. wovild ta.kie* place i;i the ^tyffes of commuting 
resourqes 4exe loped, or mjaintfairied by ^,n institution? ►Whax impact 
-would a network, have on esitablished- inst^/tutional policies? v ' / 

The; characteristics of a network- and the ways 'it might' eVolVe' 
in, the face of collective institutional choice^ also need to ie J 
examined. What, types of^decisions or, policies relative to the.' 
network must be established 'by univer^sity resource managers, •us er.s , 
and .top-level decision makers? To* what extent and in what area^ 
4| centralized management of the network regtiired?"/ What contra.c- 
t^al arrangements should bfe made among buyers, suppliers, and 
network administrators? How should prices be se,t? ilow should' 
^invoices For 'services rendered be, handled and* accounts paid? ' * 

These questions can be examined only an environment ih 
which ,the implications of such policy questions can be observed 
in* concrete .t^^nis . Moreover, that environment -must, not be con-* ^ 
strained by- a 'priori solutions* to th^se issues* In particu^lar , - 
questions o£ network management and Control must be left open. 

No fxis'ting network\has the necessary characteristics to 
examine all of the important issues. The ARPA Network, for example', 
is devoted -to Department of Defense activities. Thus it .is not 
suit^le 'as a basis for studying the implications of an economi- - 

call);; viable general networ.k linking diverse educational institu- 

♦ * ^^^^ • • 

tions and a wide spectrum of users. 

r 

The u§e of a real network. to examine these issues, while 
advantageous .in some respects, poses^ a number of almost insuper- 
ahle problems* It would be extremely cjAstly, take several years 
,to impleni'ent, severely restrict ^t"he jjumbeT^nd scope of ' approaches ^ 
and alter^iatives.^that could be investigates, cisrupt the normal 
operation bf the network, arid require sig'nificknt commitments' of 



* int'ei lectual and other resourcfes. Consequently, such'an approafh 
would ribt be 'Considered- without an ovep/helming demonstration 

.that th« likely benefits wquld ^us^ify the costs a^id risks of 
experimenting with. a real network* With present ^knowledge , *no 
siich demonstration is possible • * • ' • ' % . ' * * ^ 

* • Jt was-in recognition df these%di^f iculties that a simulation^ 
apprjJach was taken to the study of a. national network.* The x>bje?:.- 
"tive was to develop a model of a computer network to represent the 
conSitioms that nrigfit prevail in a real networking environment. , 
The simulation approach permits an effective explpratioil of the * ^ 
potential iippac.t upon an» institution bf participating xn a network, 
as weli as an examination of the way? in» Which that environment ' \ 
is affected by the decisions atnd policies of participating institu- 
tions. It provides flexibility in; the types of networJ^ing situations 
'that. can be , considered, and allows for the testing of ^ variety of 
alternatives a$ a relatively low cpst.^ . 

The d'evelopmefit of a large simulation model is a complex and 
difficult undertaking? and must be carefully plaxyied if it is to * ^ 
be effective* In pjd^r "to do such planning EDUCOfI brought toj^etiier 
a group of e^ht individuals knowledge.able in the ai-eas ^ot'!. - 
model building, gaming, economics,. -resource sdminis^tration^ arf& ' 
educational computing. After an initial feafsibility study,' NSF 
support was secured fori an intensive planning study (NSF grant 
^GJ-41429). Over a six-moath period, assisted by the\EDUCOM"staff;^ 
these individuals established the specific goals and objectives ^ ' 
for such a simulation and g^i^g 'project, outlined the data- to be ' ^ 
collected, selected the initial W participating institutions, 
" determined the level of detail ahd framework of the basic network , 
, model, and prepared a detailed pl^n^'^'^ for the actual cond^ict of, . 
the pyoject^ ' * . \^ • - ^ 

*EDUCOM is a doirsortium of more than 2*0t) colleges, universities,, 
and non-profit organizations tihat serve higher education. Itj^as * 
Tounded to, .help its members make the most effective Use pf computer 
and communications technology; ^ 



•B* ' Objejctives, Of the Project 



'The project jirovides a siisulated environment in which two - 
principal objectives can be pursued- The first objective is to 
explore the pa^rajneters that govern network behavior and ta isolate 
and .examine those elements critical to the success or f ad3||ij^e of 
a network. The' second objective is to help institutional .decision 
makers develop ap<understanding of tfie impact of a n^ional network 
'on their internal resource allocation process. / ^ * 

. The first obje,ctive requires investigation of a^nuHiber of - , 
issues critical'to the behavior of a network. - These. can be clas- 
sif ied- into^policy issues and structural issues^' Policy xssvl^^- 
include' pricing,- funds f low,/network standards, seryice/guaf an-^ 
tees^ u§ei- support, marketing ,; ^nd capacity adjustment. These . ^ 
issyes are all .closal^y tied to the various 'altemst^ive structures 

c * . • 

for network management.. Accordingly , several structure^ have been 
hypothesized, spanjiingr the spectruin from aTlodse set of '^'tftdependently 
'initiated bilateral agreements between individual, institutions, to 
-a hjtghly structured 'and centrally managed network. Each of the 
policy alternatives will be ejcamined^TirT^he light of thQ, various 
suggested network structures. • • 

The secprnd ob jectiv^ .ol^he' ^tudy is'to improve each institu- 
tion's ab'iiity to make decisions and establish policies '^pertaining 
to networks. Decision makers need clear insights about the impli- 
cations of their policies^ as well as the implications of network 
actions on their own, institution,^ Gainiir;g-'such insights in the. 
' complex real world cart be very difficult and exjiensive. ^ y 



the data already collected indica^te that institution 
administrators often do.^'hot have suf f ici^nt^ cdntact with ne^worksr ^ 
to have established clear policies, governing network situations.. 
As a consequence, policies, where they exist, ar6^ often incomplete 
and inconsistent and. .may' contain unanticipated implications for 
the institution pr for the network. Feedback to administrators 



from the model -basSfd investigation^ should clarify the ^>resfent 
iirtuition- based conception^ about the impact of theit policies* ^ 
' iijie ®odel ^ill. algo.be employeid to study* institutional policy ' 
^pofitiqps and to assess the lively advantages and disadvantages 
(j£ Various modes of network participation. Working i^ith the* 
y project is ttus aiding administrators^ in obtaining a much clearer 
understanding of appropriate network policies, for their institn- 

T • ' ' . ■ ^ - ' * • - . 

^ * & * 

; Several participants in the network simulalTion project have 

also ^expressed interest in gaining^ information abotit the possible • 

markets fpr, 'and the potential external support requir^eraents of, 

sipecializred resources that they might offer on- a netvork. The-'. 

derivatrion of this type pf information from the study should 

assist these institutions in planning their computing activities. 

. Other institutions are presently engaged in bilateral resource r* 

exchange agreements and need more information about the likefly 

implications of wider resburce shari^)ig^ A third ^grbup wants te 

explore the possi'ble implications of red^fcing or eliminating 

selective in-house services in f-avor pf outside suppliers . Finally, 

and .perhaps aost numetous, ate the institutions that have a strong 

liteed? for limited access to sophisticated facilities arid services ^ 

foa^'^^ply* cannot be justified intei^ially. Hany small college^ 

(and ev^csome very large universities) throughput the country would 

fall into this last category* , , 

An important by-product of the study will be thfe derivative ^ 
impa.ct lipon the institutions that participate in the prd^ect. 
Adm^inistrators/T^.usefs , and computing center directors are collect:ing 
data ,-9.boJ0ft: tft^ir computing activities and^ examining |:hem.in detail 
in c^operatHl'on with the project staff. This experience appears . 
ilkel)^o' inf lueiipe the attitudes ^of decision makers, about the 
. I^Vays '&wbjb<^,net^r^^ can be applied effectively in support of 
?j^sear'eh4^nd ;6ducation* 

- V * ..A clearer, understandinf of network behavior will be useful 



not only to policy makers at ^each institution, it will also', be 
valuable to a wider g'roiq) interested in networks. For e^fample, 
Federarl policy makers who are' corfcerned with the effective utili- 
zation of the nation's computing resources are likely to benefi^t 
from a close scrutiny of network behavior. Computer 'scientists 
and other researchers having an intellectual interest Ixi networks ^ 
can use the model ^to explore various* hypotheses about networks^ 

The programs for the simulation model and gaming study *will 
be made publicly available- This ^5rill allow institutions and 
researchers outside ofsthe project to conduct ^Ji^ir own studies 
and ^se the model for improving their decision making* Coiisil-erable " 
effort, is being made to make the computer programs as modular . * . 

possible %Ti ordef to foster such us5. - ' ^ \ 

C. Project Phases ^ ' • . ^ 

The overall project is broken down into three overlapping 
phases. The first phase ' — the subject of this repoi:t --'resulted » 
in development and use of a simulation model. The second phase will 
focus on decision inajiing at the individual participating institutions. 
It calls for tailoring the model to each institution through refine- 
" ment of ''the data that describe capacities, ' demands for computing, 
jnanagement policies with respect to compCiting, and 'the like. The ^ 
final gaming phase calls for administrators at each particip^ing 
institutioxi^to make decisions in a simulated network i.e., to set 
policies as events unfold to them in Simulated time. • _ * ^ 



Pha^ I efforts haye been primarily concentrated on initial 
data collection and the^ design and programming of a cdmputer simu- 
lation model. Design^f the model adheres closely to a "^p-down 
structure. Thus, the model consists of a hierarchy of mooules, with 
each module relatively independent "of the^ others . A module is kept 
fairly small* and is confined to a limited and Well-defined task* 
This ap^oach permits modification and ^volutio'n of the^'model; since 
it ^llow$ extensive modificatidn or re^acemeTiTjof a module without 
affecting o,ther modifies and without changing the overall structure . 



of the model . . " ' 

. . . \ * • ' ' ' \ 

The model, has been used durmg. the last part of Phase I fox 
explo^^^tory simulations* to investigate a variety of possible site 
and network prac^tic^s- and situations. The objective has been' to 
i^solate^ and' examine those par^eters that are cri,tical. to network^ 
de^ibpment and success. ^\'' 

Phase II begal^lbefore comp^letion and. documentation of the 
Phase I simulatign analyses^ ^ . Focus during the second phase will 
be *on* the detei^mination of the actual policies dnd practices of 
the participating institutions and on the insertion of these, results 
into^the model* .The implications of each institution's actual pdJli-' 



V 



cies and practices, on both, the inltitytion and tb«t^gt.work, will 
be, reviewed^ with the partit:ipants to determine the reasonableness 
of the .deci-sion rules used, in the model and plaiasibility of th^. 
simulated, resul ts . Jhe decii^ion rules ^will be r^efinejl as appro- 
priate^fhrpugh an iterative ^xpcess, ' ^ ^ 

t • * * 

, Phase III will be initiated in the second project year (in * 
parallel with Phase II) and will ccotijiue until the end of. the 
third* year. \he maj or«:or ientation of Phase III will be toward . 
a* network simulation analysis mad^,.in_a group gaming environment. 
Par4tix:^ants Ifiiil dynamically make decision^ and alter policies 
based on the reflected implicatiojia of earlier decisions. Thus, >' 
they will have to ''live'* with the ^conse^ences' of their decisions* 



D. Organization. and Con4uct'of the Project ' \ 



tThe simulation and gaming project has been conducted as a 
cooperative effort from its very inception. The original planning 
study grew out*of a. number of early discussions^ organized by Henry 
Chauncey, then President of EDUCOM, and several networking airthorities 
In order to formalize widespread participation^ a group of ei;gnt 
'•cooperating investigators" were drawn- from various educational' 
institutions to serve in a continuing' advisory capacity |, throughout 
't^e life of the project. The cooperating investigators have. l^r oven 
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to be extremely helpful in gene^afing creative 'ideas, cautioning 
again^i: possible pitfalls, and providijig feedback response to 
work done by tbe^'reSe.arch *staf f • "Membership^ in the cooperating 
investigators panel is as follows:^ ^ ' ^ ^ * 

4 • 

D^. Robert L. AshenVurst ' * ^ * Dr. James R. Miller ^ 
Director, Institute for Associate Dean v ^ . 

• Computer Research 4 . Graduate School of^Busiliess 

. University of Chicago ^ ' St^anford .University 

* Dr. Sanford V. Be^rg_ ^Mr. K. Roger Moore 

.Assistant Professor' • - Texas Tech University ' 

Department of Economics— •* 1 

University of Florida ' Dr. Charles H* Warlick ' • 

' * • ' . • ^ Director, Computation Center 

0r. Donald Kreider University of Texas at Austin 

Professor . ^ - " , 

Department of Mathematics * \Mr. ,Joe B. Wyatt 

Dar^outh College Vice President for 

•Administration 

< * ' ^ c • JJarvard ^niversft)^ 

Much of the detaile'd work during the earlier planniii^ .studies 
V • was conducted by ^)r. Norman Niels^eit of ^he Stanford Researclj Insti- 
tute. Dr.' Nielsen's experience as a computer center manager -and * 
his research pn networks and resource allocation uniqtjely^^quipped 
^ him to 7)rovide' technical leadership for that project, Followinrg 

the completion of the planning study; he has continued as piroject 

* 

consultant and provides frequent advice and assistance to' the 
EDUCONt project staff. , ' 

V- Dr. Jamas C. Emery, President of EDUCOM, serves as Principal 

Investigrtor of the project and is responsible for its overall 
direction* Mr.' Ronald Segal, ,of the jGraduate. School of Business 
at New Yojrk University, contributes much of thfe technical leader- 
ship, as well as day- to-day^ administacation of the project. Ms. 
Beverly O'Neal serves the project on a full-time basis as systems 
' analyst. During Phase I, Dr. Norman White,of NYU and two otht- 
I stafiding NYU students, Mr. Steven Bensinger and Mr* Joseph Puglisi, 
have provided analysis and programming assistance. A full-tiine 
secretary/administrative assistant, Ms. Deborah -Brown, has pirovided 
yarluable support. The staff of another EDUCOM activity, the J^lanning 



toimcil^^ .On ComiJuting in Education and Research, wqrks closely 
with I3ie Simulation anjb Gaming Project • (The Planning Council 
IS a joint activity of tweftty-^wb schools with a mission to ex-' 
ploT^- and implement the use o£ networks to ^tfe computing resources* 
Nine Planning Cpu!ncil institutions also participate in^the §jjaulation 
and Gdming Project), - • . . 



MudFpf;the detailed 44 ta collectidn f^r the project %s pro- * 
vided by personnel from the , participating institutions • Eaqh , ^ V 
institution contributes the, time of a senior administrator, tl|e^ 
director^ of computing activities, and a "liaison coordinator." 
A research assistant is supported by project fuftds to assist the . ✓ 
liaison coordinator .collecting data for input into the model* ^ 
The individuals that served in these functions 'during Phase I 
are shown in Figure II- 1. 

Th'^e regional meetings were.he^d with institutional representa- 
tives during the fall of 1975. The' f ir^t was held in Palo Alto/ J 
the next 'in Cambridge', and the final one |n ChicSigo. The purpose 
was fto meet the institutional representatives, to discuss the 
current s.tkte^of ^the model, and^ to outline the role that the^insti- 
tutioirt^!:were expected, to play. The meetings proved to be invaluable 
in removing some of the ambiguities in the model design and data 
collection questionnaires. They also provided a very useful forum 
for^general discussion and gaining the benefit T>f the vast and 
^yaxied experience of the participants^ 



'Jo the extent possible, the project has utilized existing 
resources available from the academic and computer science comm'unity, 
rather than attempting -to build its own staff to 'duplicate existing 
capabilities* Consistent with this philosophy, several well-defined 
tasks have' -been contracted 'for with. academic institutions and othej^ 
technical organizations. &r. Norman Nielsen and some of his col- 
leagues at Stanford Research Instityte (iX particular. Dr. Clifford 
A. Isberg and Dr. k\ Robert Tobey) have w<2^ked on several of the 
more challenging technical problems principally the definition 
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of computing service types and* their translation into computing 
resource requirements. Dr. Jed^rey P.. Buzen' of BGS Systems' ^Inc, (whq 
is also 'affiliated with Hary^^rd .University) has applied his wprk • 
in networjf queuging models to 'the modeling and prediction' of 

perf oi^nance 'on a computer system under va^ing wo^rkjoads. Both 

\*' **' • 

of the tasks are critical to. the overall project; and both organi- 
zations bring jto -^e^r pn their assigned ^robjlems experience and 
skills "that would be Very, difficult Cif not impossible) to duiJ-licatfe. 

GiVen the decentralized nature of theprojeci, *it has been 
essential to provide central coordination and guidance^ This has ^ 
been, achieved through a metic^ilous specification of systems design 
and programmii)^* s t andaf ds , careful documentation combined with ' 
dissemination of information- to participating groups, and. frequejit 
technical reviews of the project with EDUCOM s^af^f "members and 
principal consultants. * ' ^ ^ 



•E. Organization of the Report 

This report is designed to be a self-contained document that 
provides a compreheRsive and detai3*ed descri|)tion, of the current 
status of the Simulation and Gaming Project . ^ It is organized 
hierarchically, ^getting into ihcreasing detai'l as the discussion 
proceeds. 

7 * Following the overall summary" contained in thi^ introductory 
section, further elaboration is given to -the model in Section III. 
Special emphas.is is placed on the design philosophy and the motivSi- . 
tions for' taking the approaches that were followed. 

Much of the detailed inv^s^tigation connected with" the project 
was broken down into a series of "background, studies'* that could ^ 
be dctne in-house or, assigned to 'decentralized grcmps. these studies^ 
are summarized in Section IV*^. ^ • ♦ " - 

■. . ;•• ■■ . .-. . -•. ■ . • 

A major activity of the project was the coll-ection of data 
about computing activities i» each of the participating institutions ♦ 
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#hfise dat.a have been colle^cted primarily through the means of 

'detailed questionnaires and benchmark progi^am's. Section V • 
discusses th€ issues involved in data cbl3.ection, describes the- 
instruments' used, and points out some of the difficulties encoun- 
tered. ' . * * 

' . ^ . . •, 

*■ • . ■ . - ^. . • 

the mod'el ^s currently being' used- to conduct a series of 
experiments to gaxn -some preliminary insights into network behavior 
■ and to identify the more critical components- of the model. These 
experiments , are discussed in. Section VI. • * 

^ Section yi I suranarizes the current states, of the m6del and : 
• other ajspects cff the project- In addition to this/ ir outlines 
the continued work during Phases II and III. 

.* ' ' ' 

The appendices gi^vrja- much mare 'detailed information for t|iose 
who want to gain a deeper unjier standing of the onodel or plani to* 
.4ise or podify thi^ model. Appendices I and, LI contain material 
^ of fairly general interest 'and are included in Volume I^ along 
with the more general material contained in the main text (Sections 
I through yill). . * • ^ 

, Volume J I contains the appendices of inte^rest primarily to 
tjiose who intend to use the models or who are interested in review- 
in^E th6 data cplle^lion or benchmarking procedures. It defines . 
run ^concepts, and outputs, and describes the, actual operation of 
the'model. Appendices III, IV and V .represent the model riser's ^ 
guide', model reference guide, and detailed^nstructions for making>^ 
programming modifications ^ The remaining a^endices contain repro- 
ductioiis Of -the two data .questionnaires, '^s well as the. ihs'tructions 
and listings of the benchmark^ programs used. - ^ 

* * * 

^ VoXtime III is available upon request and gives still' more " 
detailed information for those needing the actual program listings 
'of the entire system in order to modify or ext6nd the model. 
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:]% SIMULATION MOPEL 



' / rt should bfe ina^ clear that this is not a project tcf build 
a *siinulati.on model ;\ rather, it i-s a complex research activity 
seeking to 'answer some very critical questions relativ^^to Ae 
future pf national computer networking for research and educational 
institutions. The si^nulation mod^l provides an.ds^ential tool to 
accomplish these objectives. By means of ^thje model,, it wiil be 

# possible to examine the likely consequences of a^wid^Tange of 
alter^iatiye network policies. Although jnost^of the effort during. 
Ph'Hse I has been devoted to the design and implementation df thi^ 
inodel, future efforts *on the project will fobus on using the model 
to accomplish the required objectives. This section describes the . 

.Resign and characteristics o£ the initial model. . ' ' . 

A. Design '-^Philosophy ' * ^ 

^ The basic philosophy of the design?^ is to provide a- highly para-* ' 

meterize.d and flexible model'/ In general, it is "policy-driven" ' < 

that IS,, its execution and the outputs? it produces depend, on the 

parti-cuiar choice of policies in ^ given 'run of the model": The 

* ^^^^^ ' 
objective is to permit the examination of a variety of institution 

and network policy, rules in order to study the imj)act of various 
network configurations, maiiageraent structures^ usage modes, and 
'growth patterns.^ Virtually eyei;y module starts with'^he input of 
^ , appropriate poli^^es, 'practices, and/or management decision. Tech- 
nical relationships are then used only. to the extent requited to 
jreflect adequately^ the implications o£ 'tliese, decisions. 

The model 'has been designed, and: implemented using a modified 
top-down, structured programming approach. The results o^this effort 
teAd to support the economies and efficjences 2,n programming, as well 
as improvements in reliability*, usually cld^med bv/advocatSs of these 
- t'echniqu^sT Considering, the size and complixity ^<Df tl^e sys^tem, it|C 
was implemented in k comparatively short tim? with a small staff. ' 
E^en thojigh most of the programming was done by relatively inexperi- _ 
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enced students, there, were no major debugging or validation problems., 
*Iii;additidn, the modularization and clean definition of functions 
hav^ permitted tlie segmentation of work so as to take full, advantage 
of thf variety of researchers and other personnel available to the, - 



project 



■pSrhaps the primary benefit from tlie top-dt)wn approach has 
^Been the,- ability , to implement a' useful working model quickly, even 
^Sou^h ^ome of the^'detailed modules remained in relatively cru^e '. 
fofm until the; Background studies and data collection were completed. 
Hence, earljr experience and^nsights were gained in such' areas as 
work ^low, -output reporting, parameter tuning, and^ smoothing of 
time-varying estimates. -This" approach will be of continuing value • 
-as experience permits an increasing sophistication -of representation 
'in some of thqt moje critical "lower . level" modules. 

> 

' 0 mention s'hcruld .be made of , the open-ended way. in which 

representations of policies and practices are included. In general, 
each policy module calls subroutines representing the various re- 
quired .policies . .A user of the model can therefore describe his T 
site's .practices and behavior^ by using any combination from a stored 
library of policies.. In future project phases, users will be able . 
'to ^pe-cify lany desired" ad hoc representation either by adding 
4heir o'wft subroutines to the library or, iii some cases, by entering 
decisions on-line. Coiisiderable fLextbimy will thus be available 
'in rei)resenting' a given institutibn, and it will be relatively ias^ 
to modjfiy or to expand the internal policy library on an on-going 
hasis^. * ■ ' 

^ . ' ' 

Hddel Ove^rview • r ' 

For purposes, of model design, the "network" has been defined * 
as- having' 20 initial sites. Eighteen of ■ these are set asidi for. 
detaUe4 repfesentationff of the 18. participating institutions on 
the pfcry«c^'. (Sixteen were 'originaj participants and two have 
recently*' joined the project.) The actual number of sites used in 
any given run* is an input variable, and most testing is "being carried. 



^ot^\i±th smaller, numbers o£ 'sites. One of.the rejniining two facil- 
ities has b^n designated as a "background" s.ite that .generates all 
work originating, from o!utside the 18.memb£trs and receives ^11 wark 
specified for locations' other than one of ^ the member sites- This - 
artificiaX site was jn'troduced to represent the characteristics of 
a full mature netvfork. The second ^xtra site, referred to as^*a^ 
"networl;" site, permits the testing of network policy issues and ; 
special service categories. For^ example,, req^uests to obtain a 
particular widespread service at ^'lowest cost" or ''fastest turn- 
around" (i.e., wi1ih<mi-^esignation of a ^specific supplier) ^an be- 
sent to this "site" for allocation to the appropriate supplier. 



The ^description of each site in the .network contaii^s Varidus 
poli^ry fopaulations and decision rules. These deal with such matters 
as pricing, hardware changes, budgfet allocations, user* support ley- 
els, and computer scheduling and priority setting. The model is 
designed in such a way that individual policy subroutines can * 
written and inserted to accommodgte those sites that cannot be 
described by combijiations of standard policies. At pre^ent^ most 
of ^he site behavior and policy descriptions have ^een selecte^ by 
thjfe project staff. Although the choices were generally reasonable, 

the primary purpose for this phase was to exercise the model and to 

* 

conduct some general sensitivity and* trejid experiments . During Phase 
II of the project, emphasis* will be placjed on formulating and speci- 
fying those options 'that actually describe the unique behavioral'^ ' 
reactions, practices, and constraints of each site. . " ^ 

The design bf-the; simulation model^has three basic conceptual 
elements: ^ supply-of ferings ind capacity,,- user demand, and the bal- 
ancing of desired demand with avaiTable supply ("Market"). Each 
site on the network is vigwed as a node having specified offexijigs - 
and available capacity measur-ed in terms of CPU speed, primary 
memory size,^Card readiAg and line printing potential, xnput/outpul: 
channel capability, on-line pqr^ts, and communications . bandwidth. 



The demand for, and supply of, computing resources at' each site; 
is expressed in teiiiis of categories of/computing called "service i. 



types/" Each service type .is presumed to include a reasonably homq- 
genefous type of ^ work. A vefy , simple model might have only two. 
Batch' 'and iiateractive • The forty-eight present service^ types* 
availa*ble should he su^f iciiP'nt to represent adequately th^ 
network resources? ' Mo rei could certainly be added, but memory rd- 
quirements woijld grow proportionately and wourd rapidly exceed the 
space available. * ^ - - 

The model operates with a basic, time increment of one week* 
Although a week- long time ificrement precludes use of the %JC^Sl 
investigating hour-by-hoiir variatioAs in the process ing>aoa<^ sb*;^! 
individual facilities, it does not imply that servica^ characteristics 
having a ♦time asnept of less than a week are ignored (e.g., shift 
"or ^priori 1?y time differentials). It was conclafcd that time inter- 
vals of less than onit week 'would be computationSly prohibitive , 
and thai input data smaller, time increments would be unreliable^. 
On the Othet hand, a weekly 'time increment is small enough to r^ect 
overall network dynamics, and to be compatible with typical weekly, . 
monthly,, quarterly, and annual decision cycles. . - 

J . ^ • \ * " • ■ : ^ 

.The mail! time-varying information in tiae mod]&i*^'S', held in main 
Itqrage in a three-dimensional matrix that contains the amount of 
each service type 'requested at each site on the network by e*ery 
other site on the netwdrk^ this matrix has a size of NSITES^NSITES* 
KTYPE where NSITESis the number of sites on the network (inclu-^ 
ding the "^'backgfbundv anff^iaetw^rk" sites) and KTYPES is 'the number 
of ^ifferejit (unique) services offered. The values of individual 
elements in the matrix. are ^updated each simulation period ' (i.e. , 
weekly). ^ > ^ - ' • , 

> A - 

Model Design • " 

^ )■.■:■.■' ■■ 

The mpdel contents and operation will be illustrated by de- 
scribing the program flow using a few of the. top-level diagrams as*, 
an example.' Implementation has been carried out by; successively 
expanding a'hd detailing the figures shown in .this section, which 
are actual working .diagrams.. jWmore detailed analysis can be found 



in'^ppendix -ili which also includes 'a full set of flowcharts. . 
This doGumlittation can be used in Jiierarchical fashib^, allowing 
' the .xeader^^ to penetrate inta as much detail as desired along any 
pktfr. . '\ 



Ny-, figure IIJ-1 shows the five major system module^. The flow 
of progr.am control -is from top to bottom; left to right. Thus, 
the jentire system is executed by entering ^'SliJRUN*! at the console. 

• This execu^ve proct^dure invoices module NETSiM, wjiich sequentially 
calls tly/modules'*INPUT, ZSETUP, etc., as required, io^aping is 
illustrated by the crosshatchirig in module 3.0. The symbol V in 
that blo^k should' be read "for every so that the module PROCES 
indica^tes a loop over all time. periods (i.e., weekly) » 

. ' "V 

^ s 

* ' 

Module 1.0, INPUT, begins, with a consble dialog to determine 
the basic conditions of the simulation * run desired number •andT 
idejitification of sites, number of periods to be simulated, network 
structure, and the like. Additional commentsj^o appear on the run 
output, such as data u5ed* or the purpose of the run, may also be 
iAcluded. Appropriate files are opened, and the basic data are , * 
read as required. . " •* . ! 

Those calculations ^hat must be accomplished before the period- 
by-period I'bopjng are completed in ZSETUP. This includes determina- 
tion of smoothing constants, conve^r^ion of raw input ^ata into forms 
appropriate for later (Calculation^ and output of a full set of- test 
reports reflecting the system status at time, zero (in the same form 

as the later test reports to he generated at weekly intervals). 

* * « 

Most of* the actual processing takes place under control of the 
module PROCES. This includes all calculations necessary ,to repre- 
sent the* functioning of the network on a weekly basis and to prpvide 
*the desired weekly reports. * 
. 

The final two modufTes, COMPUtrand GENREP, do the nummary compu- 
tations'and reporting npcessary to-^tepresent Site and network behav- 
ior as a fiinctidn of tjlme.^ Included .here are such area'sTas coimnuni- 
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cations load, capacity growth, cash flpws', an4 network utilization.^ 

• Mdctule 3,0 m. Figure III-l is expanded in Figure ITI-2 to 
provide an overview of the ^eelcly processing Sequence. In each 
time period, the. model sequentially handles ,all exogenous changes , 
supply determination, network demand estimation, Snd the balancing 
of supply against .demand (market analysis^. Period analyses are 
then perfbnafed and all required period reports *are generated. Each 
of "dm indicated modules is entered sequentially as follows: 

1* XOGEN - Exogenous changes are defined as any variable ^ 
changes or policy descriptions that cannot be handled analytically 
in other modules If such a change is- to be Jivade, it is ^^ntered 
h^re and put"- into effect directly. These changes override the v'ari- 
ables and quantities, that are otherwise develop^, aijalytically in 
later modules. Permissible changes include sites being added/dropped, 
major hardware changes at a site, revised policies or practices at 
a site^ and changed network parameters* Eventually, in the gaming 
mode (Project Phase. Ill), this module will be enhancfed to permit 
on-line control over virtually every model parameter ^nd "policy. 

2. SUPLY - Current computation capacity "^and offerings are 
determined in this module. * These include (Figure II J -3) supply 
policies ai^d practices, budget and financial constraints, * Hardware 
.and systems software, service offerings, prices, Ind level of sup- 
port seryices. , ' \ ^ 

3* DMAND - Demand estimates at each site are generated^ (Fig- 
ure III-4) in a multi-step pi:ocess. After the overall policies 
on demand are evaluated (3*31), estimates of demand for each u§er 
category at the site are determined (3.32). (User categories 
(Section IV. G. 2) are defined to be relatively homogeneous 'aggrega- 
'tions of users at a site, such ai students 'or funded researcilfers.) 
The "base" level of 4eniand fcjr a given user categdry is determined 
as a function of its most recent demand and site growth.. This 
initial estimate is then modified by seasonality factors »(i.e. , 
summer, end of semesteY, spring recess"), budgetary restrictions 

^ ' -28- OA . ' 



on the .users, and expected turnaround C^esponse), price, ind sup- 
port* The final module (3.33) in this section converts ^the^ .overall 
]^ demand, estimates into specific requests for ^ervices (i.e., statis- 
tical paclc.ages,- interactive editing, e'tc, see IV .C' 3)",* and then 
allocates these requests among available suppliersT * 

' ' r ' *- . . ' 

4. MARKET The market analysis routine matches the suppliers" 

and /*demanders," taking into ^?ccount sdipply constraints, scheduling 

prioif^ities, commiinicatipn b^ndwidths , etc , As a result, demand for^ 

each service type may be reduced because of various capacity con- 

.straints* These calculations result in the' demand matrix alluded 

to in paragraph lll.B which describes .the soirrce and destination of 

all services, supplied during the current time period. 

" s * 

> S. ANALY - The analysis section provides ..suCh auxiliary compu- 
tat^ns as the determination of site turnaround and/or response 
times, support le^•els, communications load, and total workload at 
each site. This module als6 performs overall network computations 
in such areas as network utilization^ total communications load, 
and tabulations of aggregate demafj^ by service type. 

6. REPORT - The report module is the last s^ec^i4^ entered in 
each time period. It produces reports by site, servite^ftype , user 
category^ and for the network as a whole. * v ' ' 

if. Implementation Conventions and Procedures 

As mentioned earlier, the design and implementation of the-., 
jnodej was carried out in a top-dpwn structured prcfg^^Ssping manner. 
These techniques are well-known ^^"^ *and need not b^e^fpanded here. 
However, because of the size of the project and its relatively de<:eif^ 
tralized management, particular emphasis was placed on implementatioSf 
coriyentions and procedure's such as 4:he following: * . 

1, Development Library ^ - The system was developed on ^n^IBj^ 7 
.370/145 under the VM/CMS timesharing system. Each of the four 
people actively involved^ in the programming had a private account 
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nuiAber, Each accoun*t number had read/write access to its own 
private dislc space as well as to the project development library. 
Since CMS does not normally, suppo^rt multiple wtitp access to the \ 
same lihigly by different users , a special set of Executive routines 
was written, to provide appropriate, access and to guarantee ^that two 
users were not updating the, library simultaneously. The library 
contains only the current^ wo rlcing version of the simulation model. 



All routines of the i;iitial model design were originally coded 
as "stubs" in order to validate the flow of the" model. Once th€f 
structure was validated/ tha stubs formed the. initial system iX^ <^ 
brary. Using this base, all subsequent modules and n\odificationS ^ ^ 
were developed on the programmer's individual account number and 
t&sted with the xurrent worTcing library model . ^ Consequently, most 
library access is on a^^read only" basis, with Jjhe write mode„ re-"** 
served far replacing* existing modules with fully validate^ and 
approved versions. As added protection, the write mode is usable 
only with an independent set of passwords and automatic baclc-up - 
and transaction logging. This guarantiees that the library always' 
contains the latest version of all validated components, and that 
the full model is always operational. In addition, several people 
can simultaneously be developing and testing new modules. Due to \ 
the simultaneous design and implementation of the model, this tech- 
nique has proved to be of Ings-tlmable value in incorporating the 
latest design decisions into the model with a minim^ of difficulty. 



^ ' 2. Programming Conventions - The iaodel has been impleidented 
using standard FORTRAN IV, 'since this, Was the most transportable 
of the suj.table languages. • ^t is highly desirable to enable as - 
jQany' institutions as possi1>le to U9^e tl\e .system on local computer 
systems,. ^ > 

Program' codlng^as accomplished on-line using CRT terminals. 
This can sometimes cause a^ problem since there is no permanent. . 
record of program changes and" no easy way to audit programmer 
, effectiveness or technique. In order to ma^intaip control of the* 
prog,rammers ' daily interaction with the system, a fea*ture of the 



[cms system was used that allows all terminal input .arid output to 
,be logged to a "console" file for later listing on ^high-speed 
printer. This was exlremely useful in the early stages of. the 
project w'hen there were a large .number of soui'ce statements 
entered every day... The programmers were able -to work without 
close ^^supervision, while the project leaders c'buld still reyiew' 
technique, help locate errors, and closely control testing and 
validation. c • ■ C" ^ ^ 

3^ Common Storage Conventions - Program mod^iles are limited 
to ^pprojfimately 50 lines (one page) of code. AU have a single 
.entry and and single ex it point T-^^ue to the large size of . the 
model, COW^N .srorage 4iad to be used. This can sometimes be a 
problem in FORTRAN, since one stfbprogram c^n change a value in 
COMMON that' may affect a seemingly unrelated subprogram. In order 
to minimize this possibility, several conventions were established 
for tfie'use of COMMW^-in tjie model: 

• Only "named COMMON" was used, thuS allowingr^a partitioning 
of COMMON so that routines only saw the information they 
need. ' \ . 



Any routine that changed values in COMMON must have had 
tlie variable (s) passed explicitly in the call s4;^tement 
and could not directly reference those parts of COhQ^ON . 
being modified. 

Copies of all COMMON blocks were kept on a separate file 
on the library disk. . If tffey were changed, the new /chang- 
es could be made rin an Automatic manner to all ^ffecte'd 
modules. This served the. three- fold purpose of mi'himizing 
keypunching and data entry errors, minimizing recodirig, and 
guaranteeing that all modules had consistent sets of COMrtON 



' Flowcharts, Naming Conventions and Model Hictionary - An 

roverall system flowchart^showing the highest levels was developed 
early in the "project. 'Sach subraodule in 'the system was namdd so , 
thatjone can easily see where it fits in- the 'overall model. For" 
•example, all routines under DMAND start with a D. In addition, 
each submodule was assigned a number that is keyed to both the 

« • 
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Ksyis^lem'^^iowcliart and the model dictionary, Figursg. Ill-S. Thp model 
^ .dict^onaiy is,,an on-line ^id used to describe all sys tern 'modules. 
[ Every module is represented by module ^umber, name, and a one-line 

description o£ purpose and' function. Addit'lonal dat^describing 
; . input parameters and variables, internal processing, and* output 
, are eiitered for many mod^^las. The dictionary .therefore serves as 
"a textual eScplandtion o'f the flowcharts ii\d aa abstract of the model-: 

Coding-^ Conventions - Each module is fully annotated^within 
Its own- code', as illustrated in Figure III-6. This includes a 
desqriptidix of function' and operation, programmer name and imple- 
mentation date, modification dates, tabulation of all calling and 
'^"Qalled routines, and a full set o^ descriptiop ^and/or definitions 
of all variables used.^ The variables are further grouped by type 
i.e^, local, common, or passed froih anothe'r roirtijie. ^Indication is 

.also gi^ven as .whether or not the varial?le is modified within the. 

^Youtine, These descriptions, besides being useful for documentation 
purpo35es and imposing an organizational discipline on the programr 
mers, werje extremely helpful in program imp^ientation and deFuggiaag, 

6^ Review Meetings - All-day project review meetings were held 
approximately monthly with 'the principal investigator, the, project 
, consultant ,^ and the full project Warn Cp^oject jnanagey, faculty 
* consultant, system^s analyst, and programmers). These meq1:ing& were 
critical for maintaining continuity of the project, since. they / * 
t ensured th^t all parties understood present status and problems, { 
as ^^11 as future plans and schedules. All meetings i4cluded|a * 
structured wal4^:hrough of the model conducted by the/pr6j,ect ^manager 
and .^programmers , with system flowcharts and listings, g-Vailable as 
requijred. These walkthroughs often identified uur6cogni2ed concep- 
tual, problems that could h^ave lead to difficulty if not reso]^ed<'^ 
; early. The reviews were, particularly useful in the expansion of / 
higher- level modules into more detailed lower level mo'dules and in 
the specification o'f development tasks for ojitside researchers. . J 

>^he -review process ensured that every team member was fully 
cony e^yis ant with al4 major aspects of the simulation model and related 
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Figure JII-6 
S^pl-e- Program Listing* 
(Segment) 



SUBROUTINE PRlCAL(ISITEtKTYPE,PRICEtPRIRESI 

cccccccccccccccccccccccccccccccccccccccccccccccccc 

C < PRJCAL ^ • C 

OETIiCRK SIKULATIDN HOCEL - PRifcE ROUTWE . C 

C • " ^.'^ ' c 

C tHIS.SUB^dUTINE tALtUU;rES PPICES FOR THE C 

SPeCIFIEp SfTE- BV SERVICE TYPE> C 

CCCCCCCCCCCCCCCCCCtCCCCtCCCCCCCCCCCCCCCCCjCCCCCCCCC 
C CflEATEO: 2/5/76 / C 

C FPOGRAMHEC 8Y: STHVc BENSJNGER C 
• C i«T HOOIFIED: 5/X8/76 JO^ PUGLISI * C 

CtCCCCCCCCfCKCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC 



c 

c 
c 
c 
c 



LOCAL VALUABLES: 

IRES^ SYSTEM RESOURCE HU«8ER 
TEMP TEWGRARY VARIABLE 

CCHMCN variables:, 

COMMON /SYSP«/NSITESfNTYPES,NRES,KCATStNOPOLS 



NUMBER OF SITES Ch THE KETrfORK 
NUMBER OF SERVICES CN Tf-£ NETWORK 
NUMBER OF SYSTEM RESOURCES 
NUMBER OF INCOME/EX«>EKSE CATEGORIES 
NUMBER QF OveRAtUPCLICY SEQ^ENTS . 

number of cash repcpts 
number'of special repcrts 
number of service specific reports 



SITE KUMBER 
SERVICE TYPE (COOE) 



PRfCE AT JSITE FOR KTYPE 
PRICE AT JSITE FOR RESOURCE IRES 



C 

C%% KSITES 
C$i KTYPE S 
CS$ NRES 
Cll NCATS 
CSS NOPOLS 
C$1 NCRRTS 
C5I NSRPTS 
CSS " KKRPTS 
C. 
C 

C PARAMEtSRSt 
C 

CSSN ISITE 
CSIH KTYPE 
C 

OIKENSION PRlCE(20;i0l»PRIRES (2C»10I 

C 

CS^fY PRICE 
CSIN PRIRES 
C 

CX% calls: 
C 

C CALLED by: ZCOMP 

C ^ 
C 
1 

c 

C*««««CALCULATE PRICE*.*** 

C 

^ TEMP»0* 

00 lOa IRES«lt9 

CALL RIFMAPCISITEtKTYPE^IRES^XI 
TE^P«TEMP* U«PR I« ES C I S ITEt iRES n 
100 CONTINUE 

C»*... ADJUST PRICE FOR PRIORITY AND STORE. 
C 

CALL RfFMAPCISITE.KTYPEtXO.X) 
PR ICE I ISI TE flCTYPE J «T£MP*X 



S 



-NONE 



WRITE{6»1) 

FORMATS IX, 'ENTERED PRICALM 




PRIOQOLO 
, PRI0002^ 
PRI00030 ' 
PRtOtfO^O 
.PRI 00050 

' - - * pRfoooao . 

PRI 90070 
PRIOOOSO 
PRI00090 
PRI 03103^ 
PRIOOilO 
PRtO0l20.t 
PRI 00130 . 
PRI0D140 
# • PR100150 

PPI00160 , 
PRIOOITO 
PRfO^IBO 
PRI00190 

fNCRPTSf f^SRPTSfNKRPTSPRIOJ200 
, , I^IOO^IO 
PRIO0220 

^ ' 'PRI00230 

-^^^ PPI00240 
PRI0325O 
,PRI0026D 
PRI0027Q* 
PRI 00260 
PRI 03290 
PP 1 00300 
PRI 00*51 ' 
PRI00320 
^ PRI00330 
PR 1 00 3 
. PRI0^350 
PRt0034p 
PRI00370 
^ PRI 00380 

PRI00390 
PRIOO^^OO 
PR IO0410 
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research activities, as well as the needs and desires of the even- 
tiial jEode}- users. It also ^served to ensure compatibility feretweert 
I3ie output b£ outsi4e researchers and the jno4el requirements. 
Hence ^ stead^^, progress on system implementation took place in par- 
allel wi$th iifork' ok unresolved design aild imple^^^tation issues. 
In'SdditiQii to the monthly review meetings, more traditional detailed 
discussions were' held • alt more frequent interval^. These did not / 
include, the entire team ^tnd usual ly^ocused ori code Vather ^than 
,design and -logic issues. 



E. -Simulation Run Requirements 



All of the jiecessary 3^un commands have been automated in CMS*^. 
Executive procedures*. Thus, the entire system is executed by simply 
entering "SIKIRUN^' at the main console. This procedure must be 
modified if the model is run ih a different computer environment 
'than the one in which it was developed. Many file definitions and * 
load and start procedures must be specified. These are described 
in greater detail in Appendix 151 - Model User's Guide. 

% M 4. 

• ' >- Si 

The sfftula^ion model depends on a fairly large data base. To 
use the mod^^^ the data' must be collected, assepbled; properly for- 
matted, aiid .i%:orporated into a set of on-line files. '|^he^ actual 
execution oi^€he simulation model is far simpler^ than tlje proper 
definition,*of the' data files, upon which it depends. 

ftll, sAJ^e^^^f the model is about 15,000 lines of source code. % 
^urre|^ly the'model requires 600,000 bytes of main jjjempry, opegr- 
, ating in a" virtual memoYy environment. Each site curren*tly requires 
approximately 300 records of 80 character? each,' although this could • 
be .reduced. by dat^^^mpression. \ ' ^^ ^ 

1. ' >?etvor}c Data - The first step ^necessary for use of the 
model is a definition odT the network* being modelled for a given 
simulation T^^^B' Parameters such as the number of sites, services, 
and time per^ms, are yemtered' interactively at the start of each 
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to Inscribe reistionship between sites* with respect to both 
.comBmni^ations costs ,^ charges, ajid prdcing structures, wiy dis- . 
coimts'or surcharges between sites must also oe included/ 

2.. SiteData^ - Once the network 'is defined, the systeSn* must 
be abl^ to access a large amount of pre- stored data for each of 
the sites included in the network being modelled. The items that 
must be specified for every site includes the site's categorization 
of computer userSo the amount and type o?. services each category 
us^s; the budget for these users and for the computer center; the 
restrictions on each category of users -as. to where job^ may ^'e 
run; and each category*s sensitivity to prices, turnaround, and 
support; The seasonality and growth of demand at each site is. 
also required. Sites that are suppliers of services must also ^ 
describe the services available, the impac^tj^f th^se services on 
the si^^*s computer resources, and the cost, ty^e, and amount of 
a'dditional Capacity that cpuld be obtained^ ♦ 

Finally, policies or practices at each site must have be^ 
defined. Where the stored menu of standard policies is not . 
adequate, new ones must be written and inserted. The policies ^ 
ate explained in Appendix I and methods for adding or modifying 
existing policies are described in Appendix V (Modifications Guide) 

3. Other Files - A number of tables (Appendix IV.H) are 
required to describe the sites bein^simula^ded. - These tables 
provide titles and text for output reports^nd includes! te n^es, 
service type names, and computer resource names^. 

4. Output - Output i^rom the model may be' directed to an 
on-line terminal, di^k files, or a high-speed printer. Available 
outputs (Appendix ril.B) ^include model reports, trace informfa^tion 
*(used for debugging), and a ib^ file. The log file is esseittially 
a periodic dump of those site values considered critical or inter- 
esting *from an ^experimental standpoint. This file may be written 
on magnetic tape for later off-line analyses. 



J*- 

'V* Model Documentation ' . ' 
*. ' . ' - ♦ 
It is of particular, importance that. this Wdel be usable by 

Various institutions and capa^Jle of being modified by an institu- 
tion to meet unxque needs not included in the general aodel, Con- 
, sequently, documentationimust be available for early use of the 
model by participating institutions during Phase III of the project. 
If ihese goals jre to^be. attained, adequate documentation has to be ♦ 
available throughout the life of the ptoject. Hence, special atten^ 
tion was given to maintaining model documentation on a current / 
basis. In addition to the usual tfextual and algorithmic descriii- 
tion5,_^%hasis ha^been given to sweral techniques as outlined 
below* ^Current versions of all documents mentioned are included 
* in the Appendices to this report, ^ 

1. System Diagrams - The basic structured diagrams described 
earlier we^ completed ^during the design phase of the project. 
These diagrams include all major system modules and illixstrate 
full system flow. Although occasional minor modificat^ions ^occurred 
in the higher levels of the diagrams throughout model implementation, 
this aspect of the dociamentation was essentially .complete before 

any significant coding was started. It should 'be emphasized, how- 
j^ver, that the lower modules are in a continuous state of expansion. 
Thus, the model will never be "complete," and evolution can continue 
indif initely without af^cting previous documenta^tdon or implepen- 
tation.' • " . 

# 

2. Mpdule Dictionaiy - The on-line -dictionary. Figure III-'5, ^ 
also was maintained on a curtent basis. Routines have been written 

^ to reorder or to extract modules in various combinations ^ allowing 
tlie on-line listing of' detailed descriptions of any or all model 
segments. 

3. ' Internal Doctimentation, - Each module is fully annotated 
within its own code as described earlier. This ensures that the 
documentation is thorough ap^ up^-to-date and greatly simplifies the 
pi^epatation of external documentation. • / " 



HIPP (Hierarchical, Input 1 Processing, Output) 

diagrams ifave^een maintaineil for thos^e modules* not adequately 
described the system diagt^s. A sajiple is illustrated in 
Figure 111-^7. Thi^ docuaentation technique is well/known and 
/will not be discussed here^^^^. - • : ' 



5* HelplFiles 7 On-^ine docimentay^ion for execution^ of the 
model and related functions was also maintained in^he form of 
'•help" files. These files contain descriptions of the form, 
function, parameters, and usage of all procedures required for 
the model execution. T^ese fries/ are contained in Appendix IV. 

" . '.■ ■ . 

.6. UsTer's- Guide - The user's^guide. Appendix^ III, describes 
the procedfares for running the model, ^e model depends oji a 
large amount of input data, the nature an^ form of which are 
described^ in this, section. The ^ide klso includes instructions 
for defining runs, creating files, responding to interactive 
requests, and^^'taining optional outputs/ This docussnt will be 
particularly useful in using the model for experiments. 

■ ■• 

7. Reference Guide - Tte model reference guide Appendix 
IV, includes , detailed documentation on all of the above. In 
addition, all majo^ variable's, programming conventions, system 
environment, files, utilities, and Executive (EXEC) procedures 
are described. ."^ * ^ 



pi 



Modifications Guide - Several model areas in the model 
are likely to re'main ,the subject of^ frequent modification. This 
is particurarly true for policy modules and report generators 
which may be altered or added for specific experiments. .This 
gui<fe (Appendix V) is primarily aimed at simplifying and stan-* 
dardlzing the procedures for performing these types of modifica- 
tions. - ^ - • ' 



Figure III- 7 
Sample HIPO Diagram 
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Gi> Validation -. 

DesigiL Validation - In a large, complex system of this 
type, one o£ the maj.or problems xjsually lies in simply validating 
that the model "does what it is supposed to 4o,** j^^^ functions^r* 
accoriing to specifications. Use of the tO|> dpw^!approach^described 
earlier permitted a contiiyjous monitoring of tl^^^w^ei from the 
*4^1iest silages throughout the 'implementation helped ^ 

to minimize this problem* , For example, at the en^of xn^oject 
week two it^was confirmed that modixle NETSIM cal'^d all top-level 
modules correctly, and that all variables and parpieters wer^ 
properly passed T>etW0,en routines. Hence, it was possible to '^sign- 
off" interactions between "modules' 1,0 through 5*0," and treat the - 
expansion^ of each of these modules independently. Z 

' 

* By continuing the above process on a hierarchical basis, it is 

possible to state with reasoijable confidence that tfee model functions. 

as designed. Although there may be 'problems in specific algorithms,- 

these are generally in the lowest level modules which is also the' 

leve'l^at /whicB continuous j^xpansion is taking place. However, such 

problems are eas^ily isolated and corrected and will not affect 

overall system function and design. 

^ 2. J^aplementation Validation - One of the difficulties in vali- 
dating„this system is that the simulation is modelling an environment 
th'at does not ' currently exist. Once the model had passed simply - 
plausibility .tests, it was clear that more refined validation called 
for a controlled environment in* which results were already known. To 
accomplish /this, the site with the most comprehensive (and reasonabif) 
data was chosen as the test vehicle and used for initial testing.-^ 
The model was run with a one- site* network, and the results compared 
to the data supplied/by the test site. This, immediately uncovered 
a niamber of discrepancies, such* as the estimates of throughput 
and turnaround, •tha't wexe^ traca4 to both programming errors and data 
errors • Once tlje^ one-site model was fully debugged, th^'si^ was 
^ replicated -^several times in ord^r to run a mulli- site , model with identi 
cal sites* The objective he re^ was to ensure that the model* did" not 



intxoducp any spurious netwofic flows • 

- A j^ood part of the model, however, is only applicable to an 
environmejit in which there aTfe network flows. In' order to validate 
tire areas of the model involved with network flows i th^ multiple 
idei^ical site configuration was perturbed in a number of wa^» 

The first perturbation was to change rthe data of one site 
in:*such a manner that it would be forced to use the netwprk por^ 
accommodate its d^and for computational facilities. To accomplish 
tjis, th^ computing capacity at that site was reduced to a fraction 
of i^sl original value, and it^s hardware budget reduced by a correr 
spending amount (thus freeing up budget doll^ars to be spent outside). 
The demand at that site was kept at the origiital level. Concqm* 
itantly, another site's capacity was increased to ensure that the 
first sitejiad a place to §o. 

bimilar runs were made with reduced prices at two sites to see 
if flow of work would gravitate to a site witli extremely low prices. 
Other^ runs were made with similar perturbations to turnaround and 
level of support.*^ The final model validation runs we r^ done with* 
each of the sites configured to exhibit "jJrototypical" behavior of 
what was thought might be possible site behavior patterns." For exampl 
'policies for one. site were chosen to exhibit cost-conscioys behavior 
wfeile* another site was defined as an entrepreneurial center. A mix- 
ture\of capacities and services offered at th§ different sites was 
introduced. The i^odel was run with these data/^o ensure that the 
different policies' made the sites behave in the expected manner. At 
.this point the model was ready for testing with site data as provided 
by the participating institutions. - ' ' 

• . * 

5- Data Validation - There were a ^lumber of problems with data . - 
validation. The primary problem was consistency. Data were fre- 
quently, found to be incon.sistint with external data and/or with 
other data in -the model. It was. found, for example, thkt sites 
had reported daily data where the model expected we*ekly. Problems 
of tijis were relatively -^easy to spot. A number of more basic 
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errors were found in such performance data as the average CPU tjine 
of the d.ifferent service types and the total number of jobs or ' 
connect hours per week. When these values were used dn the model, 
'anomalies were often discovered, such as estimated CPU use that 
exceeded the total capacit/ available. These errors were ^^g^ected 

by running, each site aloiie in the model to ver^fy' that all the 
Rapacity utilizations were, rea^io^ble and that the correct number of 
fjobs'were being run in each ^ the service ttoes. ' ■ 

r ^ / ' - . 



The hardest data validation problem was in the lack of consistency 
in the definition 'of^,.&€rvicS types. Each site was asked to give its 
estimate of ^the^number of jobs of each service type run per week, and 
what the impact of each 'job was" on that site's resources. Unfortun- 
ately, a "small FORTRAN" job on IBM 370/135' may jiot be the same as 
a "small FORTRAN" job' on a CDC 7600. In order to discover dis- 
crepancies of this typfe, a program was wrj.tten to .tabulate and to 
print the resource impact factors for all sites for a particular 
service~type . By comparing this to benchmark data for a small set 
of service typesf, it was then possible to discover and resolve -many 
of the definitional inconsistencies between sites. 



4' Future Validation Requirements - Needless -to say, in a ** 
developing model such as this one, validation is a reoccurring and 
non-trivial concern. For this reason the validation process can 
never be called complete. It should also be recognized that veri- 
|i<^ifion that the 'model performs "correctly" as described above, is 
the easy part of the validation process. More difficult is iferifT- 
cation that the model is a useful representation of the-if^alT world. 
I.e., is it simulating the right things, and if so, does it.operai^fe- 
at the right level of aggregation? Is. it believable; j^an dedisions 
be made base'd on the tfodel results, etc.? This deeper levej^of 
validation is not yet possible with the existing model. It will 
begin in Ph^se II when the model is .enriched with es,timates of the 
actual decisions and policies of t;he participating institutions.' 
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IV. RESULTS OF BACKGROUND STUDIES 



A. Purpose. and Approach . • _ ^ . 

In parallel with the de'sJgn and implementation of the simu- 
lation model as ^described in Section III several different areas, 
were i-djentified in which algorithms, procedures, or new representa- 
tional concepts were needed,. The results^.jof these efforts form 
the theoretical .base for many segments of the model. It. should 
be'nited that these studies were all,. undertaken to fill specific 
nee4s of thfe model and/or the project.* Although virtually all 
of these topics represent areas where there is a great need' for 
basic research, in-depth efforts were generally beyond the scope - 
of -this .project. More t/pically, emphasis was on doing "what 
had to be don^" Ah order to obtain reasonable- representations . 

The approaches varied over a wide spectrum.. A number of studies 
(perceptions of computer services, user categorizations, user serv-, 
ices and support) perf ormed~by~~tEe project staff ionsist^d of con- 
tinuously evolving a representational framewbrk until a point was 
re^iched .that satisfied both outside reviewers and model requirements. 
Other studies (i.e*, service type definition, benchnlark testing) 
required that vast amounts ^of empirical data be collected and. tabu- 
lated. In some cases (network organization alternatives, user 
, services and support, and pricing) iriforraal discussions vere held 
with recognized experts and some Relatively subjective "conse^nsus" 
opinions were reached. 

In two of the most critical areas (performance modeling and » 
estimation, and workload representation), outside experts were ^ 
available who hak done substantial amounts of relevant research, 
anfltt.it was. only necessary to support the extra, worjc req^iired to 
adapt the proven technologies to the model requirements. 

This chapter summarizes the results of many of these efforts.^,. 
"The variation of format, sophistication of research, and depth of 



analysis reflect the differences in model requirements; and 
ifence in the definition and pursuit of the individual studies. 

~'~ ------ -- , * 

B. Network Organization and Administration - 

Althotigh technical issues are sti^ important fa^:tors in 
establishing a Computing network, the dominant impediments to. 
sharing are very likely to be. non-. technical in nature. Accord- ^ 
ingly, a major concern^ o'f the/Study ,was an examination of a wide 
range of organizational and administrative alternatives that might 
influence the behavior of the netw15rk. - ' 

♦ • • \ , , ' 

It was necessary to identify th^se Issues so that the model 
might be brought to bear on their analysis, on many leve-ls during 
all phases of the project. Thes^ may be examined through use of 
the model in a variety of _ways. Some- are clearly policy decisions 
that may be studied* by a proper combination of policies in ^the 
appropriate areas of the- model. Others represent constraints or 
a range of possible considerations which* may be examined by proper 
specification of model parameters or input data. Typical issues ' 
of direct concern are the following: 

# Jlletwork administration including, consideration of the 
location of cpntrol over accounts, billing, resource use, 
types of services offered, administrative conventions. 

t Centralization including consideration of centralization 
of gen^ral^ capacity, the 'centi'aliza'tion of specialized 
capacity or services, the relation between -economies of 
- scale and economies of specialization, and 'the relation ' , 
• between' economies and disec^jipmias of scale for* various 

types of services 

t Methods of charging for centralized facilitating services 

(e.g.^, billing, user services, etc.),- including fixed monthly 
fee, unbundled charges for each service rendered, and charg- 
.es^^levied against suppliers. ' ^ - 

Control over prices by a 'central network organization 
ranging from ito control, at allirto detailed price regula- 
tion. Includes consideration of subsidies, restrictions . 
pn. "unfair" price competition, and standardization of prices. 
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f /^Iternative^^pr aTrangements including "spot^. 

* versus long- term contracting / fixed monthly charges 
vermis charging for each service rendered, and differ-. 

~ : ential pricing (e.g. priority level*, peak versus off- 
p^akj;' etc*) ^ , * ^ - 

# MeeJi^nism^ for -billing ;iid reporting ranging fnom ^ V 
^bilateral arrangements between each, buyer- seller pair, v 
to Multilateral arrangements through a central network 
organization. *. - 

*. . . S 

# Alteriiative budgeting, arrangements^ user institutions 
Tanging from centralized .budgeting of the computer center 
(i^ith allocation. ^ capacity through non- discretionary 
"computing dollars'*)^ to revenue generation for 'the 
computer center through a cost recovery ilechanism in 

_ ^ which users are charged- "real** money; "\ 

• - ' ^ *r 

• Capatcity adjustment -- including consideration of the 
ability and willingness of l-nstitutions to reduce (expand) 

_ local capacity in response to an increasing net import 
(export) of services. 

• Resource migration including consideration of the possi- 
bility that the "r&source rich" might become richer while 

: the '.'resource poor** might become poorer. 

% Seivi<;e guarantees ihc^luding consideration of supplier 
guarantees as to price, quality, and quantity of services 
provided and purchaser guarantees as to the quantity and 
timing of purchases. 

# Mechanfsms for -providing user services'-- (©•g**, written 
documentation, on- line 'directories, consultantSL^-etc.) , 
r'amging from direct service from the. suppjier, to service 
from a local "distributor 

• postwar e.dev^elopment including consideration of develop- 
^ Wnt incentiv^s_,^^royaities, and support of development- , • 

activities 



After reviewing issues such as these j it was decided tliat . 
seyeral^^pgroaches in condonation .would be needed to .encompass the 
wide variety of possible network organizations 'and administration!!. 
As a result there are currently two basic methods of representing^ 
thesf in the model. One is through the menu of policies available 
to represent various attitudes and decision-mraking behavior at, 
individual ^ sites . The other is through network paramete^rs' which' , 
"may be: *selQcted for Jhe network as a whole. Policies are disciisjse^ 
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in detail in Appendix II and the parameters are reviewed in Ap- 

pendittf III erf Volume 11. Most of'the'woxk Murine Phase I has 

.focused on making the model adaptable and rich enough to accommo- 

^- , date a wide range ^o£ 6rganizational. and administrative alternatives 

y ^ TFuture project phases'^ill therefore be^, ablfe.^ to, examine these 

; - H ' Issues in more detail. ' ■ . * . , ' 

, C. Representational Concepts , ' . - ' 

\ ' ' , ' • ' ' . . • * 

_ . If the simulation model is to^portraj* a possible "real'' n^- 
worTc; tKe structural elements of the model must be reasonable _ 
approximation^afc^eir- rieal life counterpart's. Consequently / such ^ ^ 
areas as user perceptions of computer services, institjltional cate- 
^gorization of users, alid descfiptions of workloads ^t various levels 
w^T'e the topics fqg^specific studies. The representations formu- 
lated >j)ro)pad^i^^^^ for the development of the 
. model r ^ V^??^ ^ - : 
^ • . ' X . ' ' * ^ - • 

^ ^ Perceptions of Computer Services - Within ^n organization, 

there are usually several- J.^vels' of perception of computer services 
and wwofikload. ^ one hand, there are administr.atoV^ who have budget 
and policy-making responsibility, btrt whose knowled ^ of comprtating . 
may be -quite limited. At the other extreme, ther6 computer 
• .center operations people who perceive Jhe'ir role as suppliers of 
raw capacity in terms^of CPU cyclfes, bits of mam memory, characters 
' ^ of input/outputj etc. .Each of tTie existing leyels at any site may 
- be represented. Currently', the model contains four such levels' 

under the general categories of; Administrator , JUser ai^a/or Supplier 
Computer Center Director^ and Performance Analyst. These different 
, levels ai^e necessary because of the rather dissimilar viewpoints of^ 
'the individuals involved at each level. ' ' ^ 

\/ . / ^* Administrator Level - Admijnistratbrs, defined as those 
V, individuals with organizational policy and resource ,^ 

; _^ jj^mmitment responsibility, are' likely to view computing 

• in terms of internal, budget liNjes within the orgaM- 
zation. Thus, one university may* differentiate between 
i *. / ' student:* jobs, faculty^ research, and administrative data 
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processing;. wliile another might view xisage and ^ 
foxroulate computer biidgets by school* (4»e», Enjgi- 
neering/ Arts and Science, Business, etcO^* In 
general, each site has its own^viewpoint and its 
own set of user categories. ' '} 



'b. User /Supplier Level - Users' an^ suppliers of serv-- 

ices 'think in terms of the type of processing re- , ~ 
*v. f»quired. A user may have, a ^arge FORTRAN program 

to run, or perhaps need for an interactive graph- 
ics- package • fndividual- users select supplier-^sites 
based 'on such variables ajs software "availability, . 
tujijarqund, .price, and Support • Installations, there- 
\ ' ^ f o/e must describe available services in^the jargod^ 
familiar to the. individuals who'will be using, thotftt*^ ' 
services,. 'Note that at most sites it is tlp.s level 
that^is closest to the network "sta'kdard" service 
• type, 'Hence ,^ translations frdm site categorizations 
* to network service types , are done- at this level and 

bas^d, on the installation's description of available \ 
ser^ces (services supplied) 

* * * 

- t. ^ Computer Center Director Level - While the computer 
- ' center director is interested , in, .and. responsive to, ' * 

the .above levels, he needs' further .information in 
order to m^ke decisions relative to configuration, ' 
staffing J system software, and other required re- 
• sources. Information such as JCPU usage, lines printed, 

# * -cards re3d, file spdce. required, mejnory usage, and ' 

^ , number of tape mounts is needed* Thus, incoming work 
at a site has to be presented in a way that a computer 
center director can' obtain this hardware J^oading data. . 
^ For him, each. service type i^s describe<^^ terms. of 
- appropriate resource requirement^ . . Total system loading' 
can then be estimated by summing the per unit resource 
requirements/ of' all jobs* in the workload. 

»^ d^ ^ Perforroance Analyst - Once ^the total workload at a 

si1^ iias been_c^ef ined, the task still remains to esti-' 
mate, site performance as faction of ^^that, warlcload . 
Cyclic queueing models and Vela ted tecJuiiques are . -. ^ . ^ 
^ currently being developed for this "purpose (see Section 
^ IV-D.2),. In^ general, these techniques require that 

the workload be describ^'ed in terms of tesource utili*^ 
, zation. This informati&n is a m'ore/\d)etailed version 
of that ifeed by the computing center jdirector described * 
above. 



' Witjiin' the jnodel^it is neGess>iry to represent each of these 
perceptiells ^nd to tra'nslate from. one to another, in this way - ^ 
. decisions made from on^^oint o£ view caiti be expfi^sed in wa^^' ' 
Meaningful to the^Vthers^^ Cuj^rently th^ administrative ley;el 
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determines the policy selection forV , particular * sit-e» Thiis is - 
t^^ically done in terms^ of user ca-tegories (or budget lines). . 
The policies then determine the methods for. handling, service types 
at the user/supplier level and,rav resources at tlie computer center 
^IreQtor level • ^eae concepts are expla.ined more fully in the 
fpllowing" sections • • • ^ 

2. User Categorizations - As, discussed earlier, the liighest 
level of perception in. the mode^l is at the adminis;trative 
levels This is where major ^policies and budget constraints origi- 
nate and are cpntrolled* iVote that administrators do not deal^ 
wj.th spej^fic computer services .or resources, but rai:her with 
broad categories of users. ^ 

Each site. has ' its bira sitg-specif ic user categories which 
represent logical internal administrative divisions. In asking 
sites to specify their user categories, two guidelines were 
provided: . % . r • - 

r \ - ^ ^ 

" a. £ach category must represent an identifiable budget 

line or funding souj^ce. 

b. Each category mjr^t pe relatively homogeneous with 
respect to rul'Ss, policies, and constraints on • 
computer usage. For example, rules for "going 
outside" would be consistent wj^thin any one user 
categpry. 

• Most universities pres'ented' categories such as: student 
instruction, externally funded research, internally funded research 
administration, external users, and ^computation center systei^s 
staffs** A research institute, on the other hand, had only two, 
''internal and eicternal users. A. few of th^^niv^rsities grouped 
their lasers alo^^ organizational lines, (e.g. College of Engi- 
neering, Law School y Medical School, etc.). . 

A major implication of the*\bove categorizations • is that each 
user .category develops its demand for computer services ind^pend- 
ei^tly 'of others at that site. Some user? (e.g., administrative 
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computing) may 1)e relatively insensitive to price and turnaround, 
fol: examplB^ while other users at thdt site (e.g», iristructioiral 
vts^TS^ may very pric^ and turnaround sensitive^ ^ In any case, 
it is necessary within the^ jnodel to: , " . 

.Permit each site to define its own -unique user 
cate>t«dzations . 




Maintain separate budget and policy struc?Eures 
for each usex^ category. 



c. 



Provide 'separate es*timates of aggregate demand for 
» 

'Computational "services for^ each category. 

Provide a means to translate (map) aggregate demand 
-for each ,categoTy into service-specific demand. 



e. .Allocate this service-specific .demand among available 
sources of supply by the application of -criteria which 
may differ ft>r each user category. ^ 

.'• ■ ■ ■ • Mc> 

, These. user categories will play an even larger rolein 
Phase II of the project, when the actual policies and procedures 
of the participating institutions are incorporated into the models 
As thfe policies, roles, and restrictions on these cat-fegories are 
developed^'l they will -evolve into an accurate representation 'of 
the 'specific institutions to which they belong. 



3/ Sei^vice Types and Workload -Representation 



Problem - One of the most difficult conceptual* 
tasks in this project was- the definition 'of .work 
(or service). Prospective network users; even 
those few that' have a good idea of what they n^ould 
like to be doing, are likeX^ to have requirements 
whose characteristics are very different than the* 
^present job stream at the desired- supplier site. 
Further, their perception of what constitutes a 



rniit of wotk, and irfiat that is worth, will^ often 
be incompatible with the viewpoint. of thg supplier. 
For example, .some of the 'pmrticipating institutions 
in this pr^^ject describe their workload using ja^-- 
gon such as: FGRTRAN, COBOL, GPSS, STATPACK 'and^ 
the like; others talk ^nly'at the user category, 
level (student jobs, administrative data'^^^pVoce^ 
and faculty^ research) ; and some prefer terms like 
compute -bound, I/O bound, large* batch, and heavy 
on-iine usage. Furthermore, '^similar" progx'ams and 
services available at multiple sites are not always 
cj^mpatible or traJtsferahle — especially when dis- 
similar hosJC computers are involved,. 

Approacji - Although, as mentioned above, little 
standardization exists among individual. sites as to 
how work (jobs, services) is described, it was de- 
cided to try to deVelop a consistent work descrip; 
tl.on for network purppses (though hone of the 
individual sites need use that 'particular descrip- 
tion). The initial goal was to define a set of. 
service types, limited if possible to less than _ 
50 in, number, such that the workload of .each 
n*etwork member could be adequately approximated 

Ixf an enumeration of the numbers of jobs' in each 
categoiy per unii: time (we^k) . Definitions of 

Service types should specify domains or ranjges for* 

a number of ^site-independent parameters such- that 

•^any job^^ regardless of origin,- could be assigned 

a category designation that would permit an adequate 

'determination of which sites might be appropriate 

foY its processing and of its processi^ig chafactdr- 

is^^^ at those sritfes. 



Other desired characteristics . of such >a classi/ication 
included: * . - ' ^ 



' All categories should be meaningful to users, 
although they need not laatcly current in-house 
groupings • * Where differences exist, a trans- 
forsiationf (conversion) must be feasible. 

^ The ^etwwt^}: categories 'should be expressible in ^ 
a form >m at is appropriate for use in perfdrmance 
analysis and prediction at individual sites. I.e., 
jobs wil^hav^^^^^owi resource requiremenfts and* • 
attributes (CPU seconds, memory words, etc.). 

All iteiffs within a given classification categor^^ 
must' be relatively homogeneous in terms of machine 
impact at' any givsen site. 



5. 



Servioe Type dimensionality • Early attempts to 
organize the categorization process yieldejl a^ 
minimum ofx^our factors, or dimensions, for each 
category definition. 



tJob Type* (qualitatfve)^ ^'-g- , FORTRAlf compilation 

f " ^ 

and execution, • on-line* data entry, execution of 
statistical package, etc* • ' 



ii. Resources Required (quanti1:ative) , e.g., process^)r 
memory, card reader, disk f/0, printer, etc. 

iii. Running* Time (quantitative); e.g., short, medium, 
long. ^ * • ~ ■ 

iv. Priorrty (quantitative). 

It was immedia.tely evident that any four-dimension matrix 
would. quickly grow far beypnd the/ 30 to 50 .element size limitation 
imposed by the- then-current simulation design. Accordingly it was 
decided that, in order to s^tay within' the size limitation, the 
Service type definitions should be based primarily on Job Type 
Xa one- dimensional list) , with multiple entries for some job types 
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to accommoaate suitablfe. modifiers relating to running time^and - 
priority. Resources required 'would be implifeit in the job t'i^e 
and .would not need a separate d.iiaension. ^ " 

The coiaplete list of service types was developed in quali- 
tative but final terms, -and each institution was asked to judge 
which tyjies best repres^ted the actual job characteristics at 
their institution, to specify the resources required for an 
average -job' in each service type, and to estisate the number of 
■"average" Jobs of the service' type which would adequately repre- 
sent the .total level for that service t^pe. 

■ t r ^ - - ' 

The ifesic assumption underlying this approach is that service 

types need not be quantitatively comparable between institutions.- 

For modeling of the internal uge of an institution's computer 

services, which probably would still constitute* the bulk of the 

services even after national networks are available, .th.is assump- 

^i^,.*^. entirely consistent. Between institutions, it? is assumed 

t^t the-^haracteristics of a job will change depending on the 

i^titution at which it is run. \ 

^ ■ . . / . 

r-^ ' ' ■■ T ' . 

For example, an ABC job of a given service- type, if run at 

XYZ university, would take on the resource requirements for. jobs 

xjf "this service type as defined by XYZ rather than as defined 

•by ABC. *n other words, ABC users at -XsZ will tend to behave 

like XYZ users rather ^an ABC users S-^ince demand is allocated 

by policy and doesn't «^ange rapidly, this assumption appears 

to be more., reasonable than the converse aSsuB^g^tio^ that a job 

originating at a specified institution wiu'have the character-' 

istics of the jobs of that service type for the origination' 

institution, independent of where the job is actually processed. 

Initial Ca tegorization - The initial list of [ 
■ ' service type descriptions was a common-sense 'develop- 

ment of the list obtained from institution- responses 
- to Questionaaire I. Service types known to exist, ' 



.... - ^ ^ . , . 

Aut not mentioned by- the institutions in their^ ' ^ 
respoiises .to the questionnaire, were added. ^ ^Sev- 
eral service types mentioned in the replies, such ^ 
as ,li\tle-used c^pilers,.were lumped into catch-all 
categories labelled "other." A number of -service 
types were repeated, with "modifiers such as "short," 
"medium," /'long," "low. CPU utilization," and "high^ 
CPU utilization." " * * 

' ■■ " 

This initial tentative li^T^Sf-service type descrip- 
tors had 42 entries in three general classes, "B^tch, 
with very restricted resource allocation," "Batch, 
general, "^nd "Interactive." It >*as assumed that ^11 
interactive jobs Vould run under the highest priority, 
assigned the number 1, and that the restricted batch 
jobs would all run under"a number 2 priority. In 
the second questionnaire, users were asked to;es- 
'timate, resource u^ag^ as a fun^-tion of p^ority 
(four levels) for each service type in the class -of ' 
general batch jobs.. There were 20 'entries in the 
igeneral batch classification, which, with priority 
modifiers, represented 80 service types, so the ^' 
total list had 102 entries. This initial'list 
appears in Xjuestionnaire II (Appendix^ VII ) . ^ 

Final Categorization - As ^resource usage data 
were compiled from replils ^ to ,the second question- 
naire, entries in the service- type lis t^' were com- 
bined again to reduce their number in accordance 
with storage limitations within the simulation 
mpdel. Little-used service types were merged with 
similar categories, and differentiations *that were 
difficult for individual .sites wtere eliminated. All 
members, of the restri^rted resource allocation class • 
' of batch j^obs, for example, were ITBTped Tnto a 
single "Fast Batch" service type. Similarly, all 
of.4:he "compile ^nd bomb or short run" jobs in the 
general batch classification were lumped into a 



si^gleVogbug Runs** service type and assigned a^ ' 
nurabej/ 3 priority. Among 'tJre interagtive ^obs, 
•the- higii and low CP]i irtilizations were combined, 
eliminating that distinction. The ;rest of the con^ 
solidation process consisted oT flumping together 
two, three, or, in sx)me cases, all four priority 
levels and assigning- a single priority number. 
The final list of' service type names has 44 entries, 
distributed as ^follows: , , / 

' ' ^ . • 

f 11 Interactive job types with #1 priWity. 
• ' 1 Past Batch entry with #2 priority.- 



t 



32 General Batch job types with priorities.^ 
ranging, from. #3 to #6. 



Fourv. additional' service type entries were reserved 
for special or unique services that a facility 
m^g5it offer. The final list* appears as Figure , 
IV-1/ * 

* , V 

Statu's - The above .characterization is useful**in 

several ways. Providers of computing services 

can describe "their offerings to remote users .In 

terms of the network standard list.' Similarly, once 

prospective buyers express their needs in this ' 

'form, they, can *easily investigate the avail- 
ability of desired servfces on the network. ' All / 

network flows (workflows between sites) are now 

eofpressed using this^ common denominator* 

It is recognized that no such list is likely to ' 
exactjymatch the services offered at any single 
site. Further, the standard definitions for job 
types m^ not be consistent with tfcose at individual 
sites. \However, the nature of most inconsistencies 
is in degred' (e.g., size of FORTRAN jobs; average 
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. Figure PV-l ' 
' Service Types * 



Service Type 



1* Fast Restrict^ -Batdi ' * 
DeJnigging Runs , 
IDKTRAN Pjpgrafli Itevelopnent 

4. POKTEM Program DerolopEasit 

5. "^SS^^^^i^Ji^XogsesA 
• 6. CGBQL Program feyelopEoait ^ 

7. O^L Program Itevelc^sasnt 
Z. OQBGL Program ItevelopBent 
9. PL/1 Progiram IfevelopsKit 

10. PL/1 Program ^Development 

11. Ass^ier Program Devel qp p sn t 
12 • Assesbler Program DevelopsEnt 

13. Other Program D^elopEent 

14. Othec Pn>gram Devfelopeaent 
Is. Otier Program Developnent ■ 

16. Gr^jhics. Packages 

17. Problem (Mentid Padeages 

18. Piqpblem Oriented Packages 

19. Siort Statistical Packagiss 

20. Msdiiia Statistical ^Packages 

21. Long Statistical Package 

22. Short Nisber Crxmching 

23. Short Nisii>er Crunching 

24. Short KiMfoer Crunching 

25. ifeditsa Nunber Crunching 

26. ffedium Nisriber Crundiing" * ' 

27. LcKig hftBEber Crundiing 

28. Siort File Manipulation 

29. S»rt File Manipulation 

30. JfediiEn File Manipulation 

31. * Jfedim File Manipulation 

32. Long File Manipulation 
35. 'Lcxig File 'ifeitipuiat ion 
.34. Data Access, Itead Only 
35. Data Bitiy 

36*. Lew Activity .Text Editing 

37. Intensive Text Editing' 

38. Texunnal BASIC 
39,. Terminal K)i?rRAN 

40. Terminal PL/1 

41. m. , 

42. O&er Tercnnal Languages 

43. CAI 

44. Interactive Problem Oriented Packages 
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coimecf minutes interactive session, hiujiber . 
of different' sizes of statistical packages that 
must be specified jn order tQ get meaningful / 

'.discrimination), rather than concept. 

< * 

Data describing present workloads in terms of the 
serypLce types sliown in Figure IV-1 are 'now- avail- 
able from most of the Participating Ipstitutions . 
Work is*urrently underway (sections Y-C^to V-E) 
to resolve the inconsistencies in conceptua.li Na- 
tion «nd tabulation, that exist between the sites. 

I 



4. User Services and Support - User services and support in 
the model are combined as a single dollar value for each service 
type offered by every site. . Each site must determine these' levels 
after taking into account both demand and supply conBTderations . 
Thus ,the single dollar level per service type, represents such 
^ diverse factors as written dociomentation, user consulting •groups, 
CAI, audio-visual aids, and telephone information. It is assumed 
that the* appropriate combination^f these facilities is provided 
at every site for each service type. The shortcoming of this 
approach is that it loses selectivity based on type of support and 
assumes^that quality is directly proportioMl to dollars expended, 
rt has the advantage of allowing e£ficient quantitative comparisons 



i a» Demand - The level of user services and 'support , 

• ^ ^ili affect the amount of demand at each ^te as 

well as its allocation among the various suppliers. 
^ _ Each user category may have a different |egree of 

sensitivity (ranging from low -to* high) to services . 
* , and support. Demanders view support as a^ingle 
dollar level. This single amount comprises two 
types of support. The first is fixed support 
which is independent of usage ^d includes such 
items as development of manuals, on-line docu- 
mentation aids,' and consulting staff. The second"^ 



^ y ' ^yp^i variabXe support, is dependent upon usage. 

This* includes printing and distribution of manuals, 
free listings, and the use of on-line documentation. 

. . b. Supply - On the supply sideV each site must detfixmine 
the total amount that it will .spen4 on user services 
. and support, and how tifat amount will be allocated 
among the various^ service types. Individual sites 
' ^ will place different degrees of emphasis on us^r 

services, and support depending on their general 
^ profile. The model, currently permits gites t^ 

distribute budgeted support; level? across the yari- 
ou^^ervice types "based on either the "unit of.d?- 
^®and" or "relative dollar level" method (or a com- 
bination of theseX^ The unit of demaad method cal- 
culates service specific support levels on the basis 
^ of usage-(i.e*, divide the number of jobs or connect 

hours for each service type by the total number of : 
jobs and conilect hours for all service types at^tltat 
site). This philosophy assumes ' thiat a small user 
requires as much center-proVided help as a large 
user. The relative dollar level method computes 
service-specific support levels on the basis of 

^ dollar income from that service type (i.e., divide 
the gross income from each service type by the 

total gross income for all service types). If 

desired, sites can also specify particular dollar 

amount^ to 'be' assigned to selected service types. 

This wt^ild often be the case, for-fxample, with 

new service, offerings or services- known to require 

' * dis^proportionately high (or low) levels of support. 

D. Computer System Performance Modeling 

1. Problem - The computer system performance modeling pr6b- . 
iem can be stated rather simply. There are two aspects: ^ 



' • ' a. Given- a desired workload (jot mix)' to be'processed' 
an ins-tallation, what is tl^ performance of the 
* -system that the user perceives i.e., turnaround 
for batch jobs and response time for interactive ■ 
applications? ' ( * "• ' ^» 

. b. Khat. is the* total capacity of the system to do w 

*''worIc?" That is, how many jobs of a given mix could 
it handle? , - . 

Both of the above ^questions are quite common and, in fact, 
must be answere.d to some degree for every new-computer system or 
system modification. There are a wide variety of simulation, 
analytical, and e;npirical techniques available for these tasks^?^^ 
Unfortunately, in this application the long -time periods, the 
changing workloads, the number of different sites, and the poor 
definition of workloads rendered the standard approaches either 
inapplicable or computationally prohibitive. Fortunately, great 
accuracy is not required, and it was hoped that analytical tech- 
niques capable of prcTviding adequate estimates could be developed. 

2. Computer Unit Approach - Initital Attempts - Early 
^alytical efforts focused on the definition' of a so-called com- 
p\iter unit vector (c.u.). Thrc.u. vector's component values 
were to, be the resource capacities available on each institution's 
computer system, such as the_ total CPU instruction executions 
available per unit time, memVj;;^ residency' requirements, paging, 
total card reader input capacity in cards per hour, and similar 
capacities for all ^ther I/O processing" and s*torage devices. 
It was initially hoped that' a common computer unit vector could 
^e defined which, for' a givsn* installation, would hav^. component 
values equal to the capacity limit of each resource type at that 
site. '^he* performance model would then requife only one vector 
^or each installation^ > • ■ • 

* * 

Central to the c.u. approach was the assumption that it . 
would be possible to describe all network jobs in 'terms of a 



small ni^lfejc^^i standard service .categories. The "model for each 

setvic^ ;catte^<^?y would include the, resource requirements of a 

single "average" job* A given demand for computer services could 

'consequently be expressed by the number jof jobs in^each seirvi'ce 

category. Resource requirements for the total demand would then/ 

be the Sum over all sjsrvi^e categories of thV number of jobs 

in each category times^ the resource requirements per job. Thils, 
y ^ ' ' ' ' ^ ' ' . 

• once the demand was estaJblished\£or a sitev .total capacity re- 

quired coul-d be determined and the correspondjLng supply in term's 

^of thaf^emand would be directly available friDm the c.u. vectorv 

* . r ' * - ^ . • 

• ■ • • ... -5' 

Given the ^bove descriptions, it would then be possible to 
develop formulas to estimate the response time for interactive 
services and the turnaround for batch services as a function of 
the utilization of computer system resources. The simplest formu 
las could be based on a model assuming a simple queueing facility 
at each site.. Other possibilities considered for the proposed 
model included the use ,of more comprehensive queueing theories* 
or other statistical models and, alternatively, algebraic formu^^ 
las based on linear or least squares curve fitting'to approximate 
graphical representations., of response times. 

# * 

. A great deal of developmental and analytical effort was 

expended developing the above concept. With the a^ssistance of 

f22l 

the Stanford Research Institute^ , a computationally feasible 
implementation of this ^technique was developed.^ . Unfortunately, 

incorporation of the results into the model wouH have required 

a prohibitive amount of data from the participating institutions*, 

along with an extensive benchmarking stud^. 

3. Revised Model - Current Implementations - Although the 
efforts towards, developing a computer unit vector description 
af work were not successful ill themselves, »they did provide 
the .framework for the simpler techniques that were finally^ 
^adopted. The concept of standard service types (Section IV. C. 3) ' 
is used exactly as developed in the above stjady and^^Lms the>^' 
cornerstone for representing levels of supply, Remand, aiid ^ ' 



• nettor^, fioffs . . TheWector of critical resources that, is now 
»carriea serves h function similar to the c.u. vector described 
above.' The difference is that, instead of an anaiyvtical de'ri- 
vaeion of tur.naround, rSimple table look-up ' techniques have been 
substitut^<. The independent. variable in, each search* is the 
most constrainin/'of the vector components. The ^ implicit. • 
■simplifying assmnRtid^, therefc)re«nis that t:^ crijtical resourG( 
are'independejit and jjja$ secondary ef f ec.ts -due tp-the' inte'racti'oii, 
of resources can be neglected. 



les 



^- • Turnaroxpd - Batch ^turnaround iS, currently esti- ' 
Slated as ,the sum of, delays due to input, processing //gutput,. 
and communicat-ions; Eof interactive response, only processing ^ 
and* communicg;^ons considered. EacQf the participating 
sit^s provided empirical 'data in tabuaar^^rm- concerning batch 
turnaround and interactive' response as a function of tjie weekly. 
load?on those system res<?«ir*ees they considered critical. Since 
estijiates of input and communioatjLon delays were consistently 
much smaller- than those for' processing and output ' (printer) *,Tthe 
current model" implementation only colisid'ers the latter two^ 
factors. ( . ■ ^ ' y 

\ The printe^toutput) delay table describes a single curv.? 
representing the weekly average printer delay as a function of • 
the degree of utiliza-tion of the printer. A simple FIFO -queue 
di%5cipline is assumed, and no differentiation is currently'^made 
b§^t^?een service types. Simp le ihterpolatioti 'is used between 
the six stored~t?ible entries-. , . • ' 

\ ■ ■ . • . ; . . *,• 

The algorithm for machine «'fthr,naround or interactive response 
allows -for. different levels of priority. By using diffei^ent ' 
ta^le? <one for ^ach'^riority) and assigning one of six priorities 
to ^aph service type, the model Represents the .difference in 
turnaround betlween ^he various setvice categories Six sets of 
tables representing interactive response ^^^|^^r student batcJbi 
WorTc, and four levels of bafch priority ^■^Sfeuded for each sit^. 
fhe nuinbei*' ofs^terminals conhectlW is the ^Wly^Mritical resource 
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used for interactive wark .{priority one). For the five batch 
priority levels, up to three different ^critical resources can 
.be incltided (e.gv, CPU, Memory, I/O channels, etc . The 
-recurrent algorithm selects the jnost constraining of the three 
tesou^ces and uses ^ it to estim^'te turnaround. . ^ 

* • ' b# Res(^urce. Capacities - Each supplying site in the 
network simulation has an associated list of its 
constraining system resource^. These resources 
- • , ^include such items as cards read, print lines, 

/ communications capability (kilopackets) , connect 
> hours, CPU capacity, I/O operations (EXCP's in 

' * IBM jargon)^, 4nd memory (kilobyte-hours). The 

capacities of these system resources, are defined ^ 

* within the mpdel as weekly -figures . Weekly capa'ci- 

♦ — * 

- ties ate a function of scheduled '"up hours, 
availability of the respurce, and rated hourly 
capacity of the resource. ^Example: ABC university 
^specifies that they can print at^ most 10,000^ lines 
/ ' • ' .per hour; they .have 10(^cheduled hours pe/^ week;^ 



and their ^average avaiJ^felity is*90%^ The theoreti 
cal weekly capacity for print lines is then: 

10,000.x 100 X '^0% = 9D0,000 lines/week. 

/ ' ' - . 

'while most resources can be defiifed in terms, of 
weekly c'^ap^city, some resaur«s "must, b^ viewed 
diff ereiitly . Typical'^examjUj^s are ^aiii memory, 
, * oh-line storage, and number i>f tape drives all 
^ of ^ which are static constraii^ts that do not vary 

• wi"th respect to time. Memory is" partially handled/ 
on a per-job basis (i .^^> ^ _w ill the job fit?),, and 
partially by defining a time related unit such as 
kilobyte hours. The impiieations of Jlimits s^uch . 
as the number :of tap#^ drivers ^re miich more* subtle 
and are not accofifikted f^Jp^n the present simplified 
model. ^ ' > 




System 'Utilization - Utilization of each system 
.resource is calculated within ^e model as the 
requested capacity pei- week divided bv. the total 
capacity ^,per week. Requested capacity at a ? ' 
site^is obtained by mapping all service specific 
demand to thaV" sifS^nto resource requests.. For' 
.example, -a short batch statistical package job 
may map into 100 cards read, 2 CPU seconds-, 250 
print lines, etc. These resource requests , are 
then- summed oyer all requested work.. 

Total system utilizartiqn (per cent utiiizatio^ of 
total*/ capacity) , is a" crud^j^but useful, indicator 
of "the, appropria.teness of the current job six, 
A mix that is suited for a particul^ machine 
should lead to efficient 'S)jstem utilization and 
thus, a low percent utilization of capacity. On 
the_other hand, an inappropriate job mix (I/O 
'oriented job oi) a CPU oriented s^teij of the same 
size) will result in inefficient use of the system 
and a relatively high per cent utilization of 
capacity,. Total system utilization- is estimated 
as follows: ^ . ^ 
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5 = Total System Utilization 
u^ =5 Actual usage of resource i.. 
c. s Capacity of resource i 
in ^ Numbex of system resources 



.'As a simplified example, consider a system with 
only 2 constraining resources: CPtT seconds and 
I/O requests. Graphically, a plot of actual 
usage yersus maximum (total) capacity might appear 
as follows: - J 
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Point A represents the actual utilization of both 
CPU and I/O, and point B is the maximum utilization 
of these resources* The ratio, of the vectors OA 
an^t^B^yields 'th6 percent utilization o£»capacity» 

System Satur^tiion - If - any constraining resource 
becomes, very highly utilized, the total. .system 
will correspondingly tend towards saturation and 
performance will be affected? This is true even, 

if, ^ue to an inappropriate job mix,. system utiliza- 
tion is still* relatively low. Thus, system satur-ation 
is defined as the percent utilization of the most 
highly utilised resource on the 'system. - 
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Note that percent s^uration will always equal or 
^exceed percept utilizations The difference is an 
indication of the inefficiency of the* job mix ^ 
i.e», they are, equal only for an "optimal" workloads- 
"\^^Pjicing .algorithms andr other policy decisions stomld 
>' therefore tead to reconcile any differences between 
. the two vectors. Turnaround estimates must^be based 
based on percent saturation (this is mathematically 
equivalent to the procedures described in paragraph * 
b above) . - 

4. Network Queueing^.Models - Future Model Enhancements - 
Recently, there has been considerable >ant,erest in ^he applicatioji ♦ 
of network queueing theory to the performance modeling of computer 
systems^^^'^^^ ♦ New computational algorithms have been develbned 
which drastically lower the^ amoixnt of computation necessary^^^^ , ' 

and it has^J>een shown that accurate analytical models can 'be der 

' (^341 

veloped for most computer systems^ . One autho^r even .foresees 

. • - f29l 

generally accepted axioms of computer performance prediction 

Network queueing model tecfiniques have been applied to two ,of 

the sites in the stud/ (MIT and Dartmoath) , and, the results thu^" _ 

far seem eupoar aging. This type of model has* an advantage over 

the present empii'ical implementation in that the effect-s ofhard- 

ware changes on throughput and response times can be easily i^odeled 

It is expected that later phases of -the^ project will us^ these 

methods of performance prediction in some capacity*/ It has not 

yet been* determined whether they are\ efficient* enoiigh to replace * 

the current stable look-up procedures )completely or should be used^ 

• • • ^ * 

only £pr periodic updates to these tables. 
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Overview of Network Queueing Theory - The approach 
used in network queueing theory* is to consider the 
computer facility as \consisting of a multiple server 
queueing system*, where "tokens" (programs, jobs, 
transactions, etc*') pass from one server to the 
next, and then 4>ack to the first server'. This cycle 
is repeated a numbef'of times for each , trans action. 
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irith potentially more than one transaction cycling 
between setvers sJ:Eiultaneously, Iil the theory's 
simplest implementation, there are^-^ly two servers, 
CPU anS" I/O. Each transaction c^jwlsts of a number 

iterations between the CPU sferver ancl the I/O* 
server. For instance^ a file update job might 'J 
consist of 300 input-output operations with each' 
operation taking 30 milliseconds and the inter- 
val between operations (theXPU seryice time) ap- 
proximately 300 milliseconds^. Thisijob would, take 
(300*0.030) + (300*a.30) =; 99 sdcon* to -complete, 
on an empty systei?. CPU utilization would be 
(90/99*100) or approximately 90$. ' However, .jfhat 
if two.^of these jobs. were run simultaneously? 
Once multiprogramming is allowed, queues can_^ 
develop at both the CPU and I/O servers. The 
situatioj; becomes even mor^ complicated when'we 
have differing types of transactions (i.e.,^-with 
different I/O and CPU service' times) , or when 
there are several types of I/O devices available, 
each with different characteristics^^ Problems of 
this type can be solved analytically i^ing network^ 
queuein^ theory. 

Current Status of Project Cyclic Queueing Research 
The., internal dodeding subrqjutines necessary to eva'lu 
ate both the MIT and the Dartmouth systems have 
beeif' complete and are opet-ation^^l* It is hoped 
that these routines can be used for several other 
^'sitei with little addif icaiiop. The parameters 
necessary to .drive ^e MIT model have been obtained 
and validated. Predictions of CPU utilization are - 
within 1%, jjredictions of interactive response 
time »wi thin 3/4 second, and predictions of turn- 
arounci time are within 8' minutes " , 



^ IncorporatiPit into the Simulation Model - InQor- 
poration o£ the central server queueing algorithms 
into, the Network Simulation model will have three 
effects on the current model: 

First, the table-driven turnaround modules currently- 
being used will be supplemented or replaced by 
^ite-specif ic subroutines which evaluate ^e queue- « 
ing model equations for the individual site. Thus 
there will be additional code required to perform ^ 
the calculations, as well a? some increased run 
time to execute the code. 

Second, there are some additional data required from 

each site* Data are needed describing transition 

probabilities as jobs zgove from the CPU server totp 

a particular input-output server (i.e., disk, tape, 

* 

drum). Also the devipe service time^is needed for 
each of the ^devices on the system. An estimate of 
-the number of jobs concurrently resident in main 
memory is also necessary. All o.ther information 
needed by a cyclic queueing model has already been 
obtained. 

.Third', additional code has* to be written to input 
and to store all the additional informatit^n re- 
quired and produced by the performance subsystem. 
Current estimates. are thaf this could be as much % 
as 15,000 characters of -storage for each site if 
e^ach si'te needs a separate performance module. 
This can be reduced dramatically if sites. can use 
the same code. 



In summary, the use of a cyclic queueing model could 
significantly improve the performance estisiation 
capability of the model.. Unfortunately, the price 
of this improvement is an increase in run time ind 
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starage rdquirementsw.* Tests liave not yet been 
made with the' £uil simulation mod^l^: ' If t1&e 
increases prove to be minimal^-it is 'expected 
that the qdeueing models will completely replace 
\ . ' the current table ^drivra turnaround modules^^^^At 

^ the other extreme, if th^ run time and storage ' 

penalties prove exhorbitant, the^queueing models 
. ^ would Jl^t be integrated into the^^main sjsZ^m. 
Rather, they would be used periodically off-line 
to compute the ^parameters of the tabular functicTns*^ 
• * ^ A likely compr9mise is that they would be inte- ^ 
grated into the model, but only^msedywhen the- 
tabulai^ fxinctions required updating*. 

*' 

E* .Site Representations . * * 

Since the model i-s intended to reflect the characteristics 
(actual or trial) of different institutions, it ®u5t_be capable 
of ^representing these with siie -specific data* The silre repre- . 
sefatations are kept as inpg^^iles so that changes tala* liters 
data need not involve changes'' to the model itself. This tech- 
*nique also allows simulation runs to be made with different 
numbers and combination of sites. The areas unique to-;ea<:h 
site are siimmarized below dnd kre discussed in more detail else- 

Whei^.' ' ' " ^,:t-— 

1. User Categories - The demand at eacrh site is viewed ks 
consisting of from. one to ten user categories, each with its 
own behavioral characteristics. These are specific to each site 
tlxough many sites have selected ^similar groupings. Typical 
^examples include: administrative users, student instruction, 
and research. These are .groups for which* separate budgets are 
provided and different aisa^e policies jaay exist. A^regate 
demand J.S developed at the user category leyel ^nd is then mapped 
iflfo^ts service type components (i. e. , the nusb^r of jobs or* 
connect hours 'of each^service type). This demand is then alio- 
cated. to sites depending upon t|ie policies currently in. effect- 
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^/ iapli user Category at a sitk may have a different sensi- 
tivity to price, .tumaroimd, support, and other :f actors, re- 
flecting the varying imiJortance which each user may give these 
interns* Each usjer category may^also have -different seasonality 
factors which reflect changes in demand levels ovei^. the course 
of a year. (For example^ student ,ttsir generally decreases during 
the summer.)^ ^ • ^ ""^ ' 

. - 2. Hardware/Sof tware Representation - Eax:h site has associ 



ated with it a ^ctor containing th? capacities of its "c^ftical 
resources." This vecto.r represents the maximum iisahle capacity 
of each resource over a week. (Usable capacity is defined as 
the average available capacity, not xhe theoretical maximum). 
Each service type offered at a site has . Comparable vector of / 
'coefficients associated with it which contains the amount of 
critical resources -required for eacli job or coimect hour of 

that service typ^e. (One unit of ^ service type is equivalent 

f. 

to one job for 'ba1;ch seryice types and one ponnect hour for 
interactive service types) . / 

^ 'In* addition to indicating which service types are available 
and the support it provides for each of them, the, site must also 
specify a communications limit for network transmission, the 
number, of scjieduled hours it is available for'us^ during a week, 
and its average availability (i.e.,* % reliability"). 

•-3. Policies - Each site*s decisioll making is modeled by » 
choosing* different policies which.it is to follow. These fall 
>»into three areas: 'demand', suppl)^ and market* 

• ' a. Demand Policies' - These determine the workload^ 
desi^red. at a site for a given period and where 
this workload should be processed. The demand 
policies are used to choose tj^^ relative site . 
^ ' sensitivities of demand allocation to price, 
turjiaround, support^ momentum, and user budget 
r es.t rictions*. 

■ ■ ■ * 
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!>• Supply Policies' -'These cover two areas, c suiiply 
^ determination -dnd supply allocation.- Supply 

^t«rBiina?j.onqgecides^^e estount of ^hardware,'. 

software service§^ava^able, budget dollars, 
prices, and support Ifevels^ Each of thes^ has 
'several policies ^availaiyie whicK may be selected 
by aft individual site. Supply allocation policies* 
describe the allocation of. supply at a site to 
^ the* various users demanding^ the available facili-- ^ 
ties* For example, one si$e may give* instructional 
users first choice of available services • These 
allocation policies become extremely important at 
heavily loaded sites. • ^ 

c. Market Policies - These policies determine *the^^ 
action to be taken if* all the requested demand 
^ cajmot be sa^tisfied. They indicatS the method 
by which cutbacks arje accomplished. 

Special Representations 

a. Discounts - Some of the most difficult modeling 

problems encountered involve the special agreements 
among sites i For example, one site may have a 
^ discouH;^ arrangement with another site. This 
allows the iirst site to buy computer power from 
the second ^t wholesale prices, in return for volume 
or other ifuarantees. ifr the model, discounts^ are 
allowed between any two sites by means of a 
count matrix whose elements are^ a multiplier for 
tj^e normal price at a .site. - 



l>. Communi c at i ons^ As volume between 4:wo sites in- 
creases, *it may become cheaper to lease a communi- 
cations line between the sites rather th#u use a 
network. The communications matrix contains a 
factor which is multiplied id)y the volume bet^en 

' 75 ■ ■ - 
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^Any two'sites* ••It is relatively easy, therefore, 
to add policies stipulating vhen a site will use 



^ the netKork and when it may choose to lease -a 
l^: - private line*. ^ ^ ' 



F. Supply Determination and Estimation ^ • 

One of the primary concepts in the model is that of the ^ 
supply of xdmputer sei^vices. Supply is more than just a source 
o£ raw computing power, CPU cycles, and available disk drives. 
It^also represents the services which are available to users 
of a system, and the support which these users may receive to 
facilitate their use of these serv4;^ces. The supply modules 
determine the amount, type, cost,ea^d quality of ccJmputing .serv- 
ices offered at each;.site. ^. 



V 



The suppily segment of the model (modules 3»2> is policy- 
driven. After init iaij^^ ecif ica^lon tof its hardware and soft- 
ware Gaffer ings, budg^j^M^ices , and user support, each site may 
selett policies and-pOTCtices which represent its actual (or 
t^st) decisions in these areas. y 

1. Budget A factor which underlies all elements of supply^- 
is_the budget. Once the budget has been determined at the adminis- 
trative level, specific decisions on jthe . lower levels of hardware, 
services, user support, and prices may^be made. Various budget 
poij^cies ckn allow changes to budget items, reallocation of funds, 
and various other overall adjustments. Specific policies ^y 
then determine what is done with the budget funds. For example, 
if a hardware increase is indicated, budget policy may require 
that sufficient funds be immediately available to cover the ex-* 
pense of upgrading, or it may -only specify that ^the projected 
increase in Revenues be suf f i<r|.ent .to cover the increase* in monthly 
rental fees»» The .supply of services can also be controlled by^ ; 
the budget. If a new software, service is to be added, it may be 
necessary to have fun<is available fo cover the- implementation, 
costs. ^ User support: is based on budgeted funds', and its allocation 
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:;depeiids on the policy chosen.. 



4^ 



2. Hardware - Rather than, represent each specific item 
o£ hardware, it was decided to concentrate on jthe resources 
available at ^ site: 'That is, the actual hardware and system 
iToftware items (vendor name, model number, release niMber) are^ 
described in terms of more ba^iiSr unit? of comiJuting power (print 
speeds, m'-mory size, CPU capacity,* levels of multi-programming) 
that are relatively site -independent. Hence, addition of a model 
1234 printer of brand , HAL might be described in mo^l terms as 
^an incremental 1>200 lines per minute of effective print capacity* 

3» Software; Services Available ^ - In addition tb computing ^ 
power, sites also offer a variety of services (Section IV. C. 3). 

'The computing capacity determines constraints pn what and how 
much a site can and cannot do*. However, th^ ^isei; (demander) is , 

^only 'interested in the software sei^vices (service types) that. are 
avayllable xh him. Network flow is repres.ented in terms ^f these 
services and a site's attractivjpness' is based pif^Vhich ser^vices 
it offers and the conditions under which^they are o^ered* This 
supply ^element can be increased or decreased depending upon a ' 
sitfe^s policies relative to the addition or dropping of particular 
service types. ^ - / / 

. ' ^ .-^ 

4- Support - Another "supply" it^fm which is offered by sites 
is user support.. This is a less tangible, but important, factor 
which affects computer, njisage. It includes written documentation, 
user consulting groups, computer assisted instruction, .audio- 
visual aids, apd other^ assistance which an installation may pro- 
vide to users- of its facilities. Although this i^ nat^always a ^ 
speci'fic item on a* budget, 'it is a real expense. Some sites 
may chpose tq^put little mdn^y into user support and instead to 
concentrate on improving their software offerings. Others may 
decide to provide^ support money to services in proportion to 
the income ifhich these* services generate^ * Each^ite must make* 
decisions such as these relative to* the iVvel and distribution of 



"supply" of user suj^port over the softn^are^' Services which it 
offers. • 

5i, Prices - Although price is not a supplied item per se,- 
it is ainajor factor in determining the. allocation of this supply* / 
The supplier of services must specify ' the .method for charging for 
these services •-^ Usually, prices will be based on the raw resources 
utilized by ,eafith job, although ,.spme sites may want to set prices at 
.the service. type level. More difficult than the setting of prices 
is the specification of policies for that setting. .I.e., what level 
of cost recovery is desired^ should selected seirvices be^relitxced in 
price in-order to encourage usage, shdu'^ user •services be included 
>in the list of raw resources upon which pxice is based? 

G. Demand Estimation - 

second fundamental concept in the model is that of demand. 

# * 
In order fox a site's hardware and software to be utilized, there 

must be a demand for these offerings. The demand module (3.3) , 
has.tfire^ basic^segments . First is the overall policy interpre- 
tation which controls the. remaining processes. The demand genera- 
tion ;module then estimates the actual totals of computer services * 
desired, and the allocation module determines i#p6re the users go 
to satisfy their jieeds. The demand generated by the mod-el should 
approximate that-of the sites, reflecting bpth^ the types of users 
and tRe types of jobs that they require. In tfrder to represent 
these two areas, the- concepts of site-specific user* categories J 
and network standard service types have been employed in the^ 
model (Section IV. C). Both demand generation and demand atf&cation 
is first h;^ndled on an aggregate user category level, then broken 
down by specific service types. ' . 

•1. DemVnd Estimation - Current demand is estifaated for 
^each user category at*' ^ site .based em sucfi factors aS previous 
demand^ expected growth, and current turnarpund^ price, support, 
and seasonality. The growth factor is specific for each 'user 
category and reflects the estimated overall growth* profile. Each 



time peYiod, the expected growth is first added to ^the* previous , 
base level of demand ♦ Thislbase figure is thenjjodif ied based 
on th.e user category's' sensitivity to turnaround, price, and' 
support, and the current levels of each of these factors* The 
demand is then scaled, by a multiplicative seasonality factor 
which talce§ into account th^ monthly variations that might" occur 
.in many user categories t Finally, the cost of satisfying this 
demand is estimated, and a14y cuts necessitated by bud^pt limi-' 
tations are .made. , • 

' Once the demand of each user category h^s been established, 
this, value is expanded into demands for individual service types.* 
The, service types demands are theii aggregated over all user cate- 
gofies at a site so that total demand can be expressed directly 
in terms of potential oietwork flows. This piotential total ,demand 
must now be allocated to. available supplier sites^ (including in- 
house) . - ^ - . . , 

2. Demand Allocation - Selection of* supplier sites for each 
user category first requires a determination of .eligible sites. 
This is based on local user category restrictions (policie^ , as 
we'll as expressed willingness of supplier sites to serve that 
institution. Then, for each service*type; a rating is developed''^ 
on a scale of zero to one for each candidate supplier. The Co- 
efficients used in tfiese rating equations give various* degrees 
of emphasis to factors such as price, turnaround, support, and 
past usage of that site. Note that this rating must take place 
at, thet^us^r^ category level iftiorder to reflect differences in* 
- ,polifcy, constraints, and, behavior ^tterns among the varipus users 

. . Two additional factors allow for" jln-hause ^pref erenc-es and 
"s*tickin5fes" or switchability . The model parameter DEBUMP, for 
in-house prefefencaft is a scaling factor on the site's internal 
' •rating to make it-appear more (or l^sss) attractive than the other, 
sites on the network. The momentum factor affects switchability. 
It is set to the* full^^value f or sites >'hich satisf ied d^Aand for 



this service typecast period, and is set to zero for all others. 



' \ Currently,' the rating equation is a linear sum oi' ill factors 
listed -above, each multiplied by the appropriate 'coefficient. 
^Mo^e sophisticated algorithms 'could' easily "be accommodated;. All" 
candidate sites are ranked based on this rating, and ffeSand is^ ^ 
allocated to the 'top "n" sites jn the ratings (i. is the dem^d^; 
allocation variable in the overall, policy vector and iridicate9- 
1:he number of different external sites over wHich demand for a 
giv'ah service t^e can be allacated). • 

The '!n^' sites with the highest rating are allocated the 
for thgt service type in direct proportion to their / 



relative rayings • (Only sites wHieh have ^a higher ir^'ting than, 
the demanding site are included. Thus, if the demanding- site 
lia^ the highest rating! it? will be* allocated all of p.ts own.. • 
Remand fir th^t ^ervAce^type.) Some demand will always be allo- 
cated in/house if the service* type is offered there. 

'*H.* Market ' 



Although' a ^p'ply of computer services may be Syailable and 
a '•demand for the3e services may be generated and allocated, ^^^e 
is ^ guarantee tha:£\ll^j>f" th^ cfemand can be. satisfied by the. 
selected supplier sites. The market module determines how much 
of the demand can be satisfied amd how to cut back if required. 
^A^ a given site, the rulei by which d^m^nd satisfied or not 
*$amsfied are actually combinations-^^^^policies and system' 
, scheduling strategies. In the simulation modelS this complicated, 
procedure' is reduced to. a set of policies which may be applied 

^^^f cJ^^ ^'^P necessary. ^JThe policies are ^xplaihed/in detail 

;in,^pend'ix II-F. ^ " 

• • ' ^/ ' ' * -*,*■■ 

. , • • m' * ' 1- 

Financial Considerations ^ -■ ' - 

* 1? 'Budget aftd Cash Flow - Early in the-model design, if . . 
became clear that a conlprehensive t^P^^^entation of eack site's^ 



.budge^; would 'have to^be maintained/ It would be difficult if 
nat ikpossible to inod^ decisibjjs which aff^ect f inane ia 1^1 ows 
wi^out knowle^geX^^ the^ amount of money ^aA^ailable. ,This is 
further 'Complicated by>tfr^^uli:iple .representation levels in 
"the Wdel,.^ 34dget infoijnatiph is thus carried at three levels 
in tJ^e*modeli/ ' ^' ^\ , 1 ; , ' . % 



Fir5.t^ Us,eT categories have 'budgeted amounts^ ftfr expend!-' • 
tutes on computer services . Se.c^n^,. the computer centfer has ^ * - 
budget 'items determining* its hardware, c<Mninunications, and 
persoimel -expensp^T Finally, 4ifee^e are budget estimates of, 

income from Iqcal trgers ars veil aS^jietworlc users. Af^fecting ^ 

••I ^ ^ " ^ , ^ . , 

each df these ar'eas .may be ^veralPjte^trictions (policies) im- 
posed by the central admiftistz^ation^nrSuch items 'as mii*mum 
permissible/ net^alance of tra^e ^^bdlow which "outside** purchas- 
ers must be restricted), cash f low*,^ or ''profit." 

^ • ' r ^ — • ^ n . ^ 

Jn order to' collect the budget 'da ta^ewry site par^ticipating 
^n the simulation study submitted annual budgets describing 
tjie major in^me and expense it'em^ as defined and requested in 
Quest;ionnaire II (Appendix' VIII) . These ar^'used to' produce 
the site budget" report (Figure IV^2) Currently, budgets are " 
based on a yearly time inte/val starting with th^firsi: veeK of 
the simulation. Policies used" with the experiments performed* 
thus far assume that net bofttom line bud^^ts (i.e., total income 
-^and total expenses); do* haiC^change with in €his yearly period. How- 
ever, reallocations of available dollar amounts among exis^ng 
budgfet lines are permitted Planned future policies^ will pe«nit 
revisions' of fdrecasted income and fexpense items based- on results 
;^and trpnds to 9«ite.^ In order to track income a.nd 'expenditures, ' 
*fhe:%odel can provi<^ each site with a cMmuJLativ^^ status* fepoist 
each "week (Figure IV-3) . ' ^ 



^ ..The .cash fiows easily be^projected tp. cover a yearly ^ 
period, so ^hat discrepancies between budgeted/ khdSactual expei^i; 
tureS^'^an be .exiamined.. Thfe specific jnanner of compa.rison' (i.e., 
this week vs. 1/Si{ annual; i(total to date, week^ rema^ing^; eic..) 
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•is a site- dependent function of* policyV - " - 

Budgets may affdfct levels of both demand and supply at a «^ 



site. In cases vhe^ a site is following a policy of free 
spending, for example, budget limits aay have little effect. ' 
At the othctr extreme there are many policies which force strict^ 
compliance with all budget constraints an^ user categories might , * 
be restjrict^d in their "demands due to monetary.^lin^its with respect''^ 
to expenditures. In* cas'fes of high site jitili^atiojis, si.tes may 
. ^pg^^de their hardware/software configuration if SuJEfici^pt .funds 
are available, -but Jifight loolc^o other alternatives ti^apose re- 
strictions on networic inflows of demand, etc.) if funds '^re lacking < 

A' ■ ■ - • , ■ ■ ••. - . '. 

2. ' Pricing and Cost Recovery - Pricing is a critical topic 
in the study as many of the experiments proposed invoPve varying 
.>pricing practices, pplicie^, ai^d reflation? • The participating 
institutions have a wide variety of pricing ^Igprit^ms and cost 
recovery mechanisjas, and it was difficult td 0evej.op an accurate . 
representation of each. The approach. followed is par^etric in 
nature and permits a variety *of algorithms and policies to be 
represented using ^he basic structure described b^low. ^ ^ ^ ^ 

Internally, the modeP carries a Single unit price associ- 
ated with each service type. This^may^e ^erived from resource 
Tisane pr set explicitly. The sites p/ovi^ed, in ^Questionnaire 

II, a list of "critical" resources. /Fpr each service type, the * 

' ' ^ ' ' > / * 

resource consumption of one job or"" terminal session* is fixed 

throughout , the simulation., Therefore, lcnowing'th4 charge^tp^r 

unit) of each reisource ^JLloj^ tke 'computation pf ^he.p^ice per 

* job as thi linear sum of the component^. ' Coajsequently,. site 

'pricing policies may fojpus on the individu^ fespurcp? '(letting 

th,e jnodel deteirmine service type 'prices) , or tfiey may function 

» ^ * ** 

directly at the service type.» level. • -^V ^ _ 

• • /■ ■ ■ ^^'^ s ■ " ' W * 

As a resul^t of .data comj)ression and manipulatipn, tl^e« ^rjuces 

computed for various sei;vice types tended^to be sliglLtly differ^t 

• ' / - ' I * ^ 



from the actual p;rices reported in Questionnaire II • Additional _ 
4iscxejmncies can be attribute'd to the use of only eight criti- 
cal resources in the calculation of job requirements and costs. ♦ 
CSbme sites ^ad^over 50 components in ^Iieir * actual billin^^^/^ 
algoritlms) ♦ While excluding non-critical resources made little 
oCntf, 3i£ference in the performance modeling, prices for some 
services^varied' consijier&bly from the stated price. The approach 
taken was to create a pseud^o-resource ^labeled "all other," the 
prioe -of which was set equal to the difference between the actual 
and m;)d«ls prices''!' This aiiowedithe tuning of prices until they 
matcheo^he routed levels . • ' ; ^ ' 

• Another factor which had to be considered was priority 
pricing which is used at many sites. In this situation, a job 
with identic&l resource requirements could have several -different 
prices depending upon the priority which it had been given. In 
order to 'Adjust the prices for different levels of priority, a^ 
second J>seudo- resource, which indicated the*priority l€Srel, and 
acted as a mtJbltiplicative adjjustment factor, was added to ^e * 
computation. \ * 

J.-* Communications . • , . 

An essential ingredient for compjfcter networlc -resource sharing 
is the existence of data communications facilities which can 
^reliably 'transport data^between network sites. The domestic 
switched telephone network, though designed for voice commiinica- 
tions, can aj^so be used for* data communications. However; when " 
used^or data, the voice network 'possesses . limitations including 
reliability, noise, and capacity. The voice facilities are often 
used very inefficiently .when carrying^data and consequently • its 
costs are high,^ ' ■ - ' - ' • « 

0 • 

I.n the late 1960 's, ^a project of the Advanced Research Agpncy 
of the Department cxi Defense was *undert3ken to explore and iiliple- 
ment a new commimicatdons technology designed specifically ,for 
data rather jthan voice. This project, known as ARPAnet, ,used a 




..technique called packet switching to demonstrate the technical 
anji econoaic feasibility of_reliable, , error-free, high capacity- 
data communications service. Ther? are currently computer . 
s.ystera.s at universities,, r'esej^rcji organizations, and governmental 
.agencies connected to the ARPAnet.. Technically, the ARPAn'et is 
'quite similar to the, inter- institutional resource sharing network 
being modeled in this project. ^ , - ' * 

The ARPAnet communications technology has heen transfer:/ed 
to the commercial sector by .Telfnet Communications Corporarfon, • 
. a private firm'.^ A lunctionally similar service is offered on 
'.•^Tl'WS'ET by TiT^iSHARE,- Inc. These communications offe^jsQ^s, called 
Value Added Networks (VAN), have the following characteristics: 

I'y widel\v distributed geographicelly ^ • 

2) high rfeiiability due to redundant connaunicat ions paths 
, j>) code conversion and terminal handling procedure? for 

a. wide variety of low speed interactive terminals 

— - 4). ^ixorJ:^€6:ectijon.and recover>' procedures — ^ — . . 

Sy '1a, pricing structure base^ on usage and not a fui^tion 
got distance / 

Since these VAN services are new available in the coiapetitive 
marketplace, the prices cHaj-ged can be considered as cq^ts. in 
^ the'aodei^ . ^ / 

•The connunications cost structure and pa/anetexs in the laodel 
are based on the Telenet' tariff. The '-specific cost structure in *./- 
the laodel' consists *tr£ the following components: 

^- • • / 

*1)'. one-time^setup or conv*ersion cost • . ^ - 

2) *fixed monthly cost • • . ' 

• ■• , 3) variable cost dire.ctly related to volume of ^data. 

Th§*one-time cost represents, any^ modifications .to the htfst 
• oeprating system or communications front required to, interface 
to the' communicationsr network* Fot the hosts at participating , 
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institutions this ^ost* estimate ranges^ froia- zero to. $25, 000.- 
The .zero ^ost applies ,to hardware for wfiTth the commtinic anions 
vendor majces the necessary software available ^ree. In generar,", 
it is easier to interface a communications froift-end processor, 
for example, than a host; mainframe. * These differences are, re-* 
fleeted in the cost estimates. It is possible in all cases .to 
avoid t'his one-time cost entirely if the host system will only 
-be*, using 'the network for a restricted set of service typesl^ 
For example, the one-*^time cost can be avoided (but the ^monthly 
fixed cost is increased slightly) i? that site restricts it^ 
supply and" consumption of network services to include only 
interactive service types.. Support for remote J>^ch service type$ - 
requires that the one-time cost be incurred^ 

^ ■ .- ■ " . ■ 

The fixed monthly cost component representis the cos-ts in- 
curred for leased channel from the supply or consiimption location 
to the nearest network entry point. There is also a monthly charge 
_at^ the^ entry poipt for th^ network port dedicated to the ^^te. 
This fixed cost c<>Qponent varies ..depending on distance between 
site an^J. -entry point and the capacity of the channel. For* a 
site located within a few miles of the nearest entry pointy using 
a channel with a 2400 bit per second capacity, the monthly fixed 
.cost would approximately $750. The capacity could be quadrupled, 
for an additional S400/^nth. T^^e most costly networlc interface 
of all .s^te3 in the project would be $16(?b and $2000 per nontli ^ 
for a channel s^paci€y of 2400, and* 9^00 bits^er second, respec-' 
tively/ * * " 



j»The variable cost component rep^i^sents the cost >liicH is > 
entirely dependent on the number of ^characters (or packets) 
which ^e carried by the network. The^ cost par^etei^s currently 
used for experiments is 60^ per thousand lines or cards' with , 
batch service types, and $3 per connect hour for typica^i low 
speed interactive service types. The^ commercial cojamunications 
network has virtually unlimite^^T^apacity. However, the chaimel 
between *th^ site. and the network entry point. has ^ cl^arl^ defined 
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capacity. Each service type in the model lias a defined re-, 
quirement (Rer^ job or per connect hour) for this access channel 
resource'. . . ' ^ ^ ' . ' ' . 

While the cost component parameters described above'are in * 
terms of Telenet technology and^ tariff s the Cost structure in '' 
the model c^ accommodate many other current communications 
setvices. For example, the telephone companies . and specialized 
carriers like DAT^ offer communication servit;es" which may, * • . ■ 
under ^ome' circumstance?, b^ mdre atrtra^ctive for some hfgh volume 
sharing relationships. Representing the tariffs and cap/cities' 
of these- is easily accommodated by the present imodel' structure. 

Present values of conmunicatiftos capacdty were, assigned 
based' on estimates ,of potential work ^low by the, project staff. 
These values will be refined. as experience i$ gained with the 
model. Note also, that_ communications capacity' is onfe of Xh€ ^ 
resources- that cani be .changed automatically aS the ne^d arises . 
if a policy def jfning p ermitted changes is provided-' ' 



. V. DATA COLLECTIOS AND ANM,YSIS 



A. Overview . . * 



- During Phase I the principal method for collecting data 
from participating ins ti^ttTt ions the use ofjffitten ques-' ' - 

tionnaires. Since the tas^s of. data c^llec'ti^ aAd model develop-, 
ment were conducted in parallel, it. was first necessary to 
develop ^ relatively unstructured qjuestionnaire (Sectioj;i V.B) vhich ^ 
would .penait respondents at participating institutions to. report 
on general site characteristics suck as available hardware and ^ 
'software, the nature of the user ^population and its /demands for 
services, and thk financial and organizational character ijstic^ of* 
each Site.* At this^arly stag^„^*fi the model development, response§_ , 
to Questionnaire I were useftil ,in defining model structures whicij 
*could represei^t the diversity of the p'articipating instructions,. 

As podel dev^^op^efrt proceeded, detailed structured *f or , re- 
presenting sites'! anti inter-site traffic were, developed to reflect 
the 'response patterns in the first questioniiaire and the needs of - 
the Simulation laodel. Since the inS.tial responses from the sites 
did'not, in gene-ral, match this model structure oj satisfy all of ,the 
data needs* a second' Questionnaire (Section V.C^was developed to 
obtain quantitative data in $i form compatible with modet'needs». The 
major ^rea where such compatibility is Essential is the definition 
of service/ types (Section IV-C.3) which can flow in the net*(ork. . 
Most of Questionnaire I€ w^s " devoted to the estimation of demand aiid 
capacity in terms of the uniform service/t'ypes*^ . . Ny 

The responses to these two quest^cnnaij^es provide the, basis * 
fo^ the modeling 'of aupnly and demand at each site .and also set the^ 
initial conditions for t»&^ beginning of mo.st Jietwork simuiatibn runs 
(i.e.^ what ,t^e site, looks iike without networking)-. 



V Since servic^s^ rather than raw machine cycled, yrill flow ^ 

in tlie"* network', each service type must have an associated unit of 

' * ♦ ^' ' n,' ' 

measure • • i.-e., a standard job. One possible approach would have 

been to develop a benchmark program for each of the over forty 

•different service types. However, the ruj«»ng_and tabulation oJ^^ 

*- these 1)encfamarks at ea^ network site wouii clearly have r^uired 

an inordinate expenditure of time and resources. Furtheii, the , 

probLem df describiijg individual site\workioads in terms of the' 

standard jobs would h^ve been virtuallV impossible. The approach 

taken (Section V; D) took advantage,^6f a coojdina^jed activity with 

the Planning Cpun^^il iii which a sjeries FORTRAN, programs were 

executed at a number of sites, including many of thg participating 

institutions. (A^ubset of this seri-tfis of tests^was run at those 

pariracipating- institutions that are not members .of the Planning 

Council.) These benchmark results are being. used ^y the ^oject » 

teatf to reconcile differences between the Job types reported by " ^ 

' the 'sites and the service typ^s used by the models* They also* 

provide a fornval set of comparisons between site?^ relative to pricing 

- . ' ^ . ' ^ . 

and resource requirements of identical jdbs. Of perhaps greatest 

• jr 

interest, they give a qjiantitative indication p^ttte ^^ide variation 
''in prices and service between institutions. Even though it clear 
that much of this vai'iation Vpuld be diminished in a network, environ- 
ment, the potential bene'fits and resource sharing .that this stud^ un-. 
covered_are very great. ' - ^ 

B. Qiiestionnaire #1 

The first Pijas? I ques'tionnaire ^as distributed to repres'en't- 

. * . * y ' - • 

a^ives of the participating ^nstitutioijs at a series of three one-day 

regional project orientatipn meetings held in October, 19^5* About • 
onerthird of each meeting' was devoted to discussion of tKe philosophy 

behind' each majqr^^ction, as well as the^spibc^if ic informatign 

\ ^ • . * f >L - - - - - 

requested. It was conSii.dered- essential that sit* participants undei*- ^ 
stand how their rejspohses were to be used in the simulatioA inodel, sa 
that, the widely varying hardware, software, and organizational 
Structures could be adequately represented'..^ After the" regiojial 
• • meetings, many telepfiotie conversations and let'ters' were, lisfid to 

- • ' . > i ^ . 
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clarify* how' questionnaire responses should reflect unique site 
characteristics. A particularly troublesome, aspect of the 
questionnaire was the definition of categories to represent 
computing ;services supplied and consumed at the * various sites. It ^ 
Was initially *felt that no single set of cjftegories- would be meaning- 
f ul to all sftes and still satisfy the model~requiremejits% Therefore,^ 
>£he resulting questionnaire presented an iilusixative categoriza- 
tion to indicate the level of detail desired, but respondents 
were expected to create categories ^hat were ap£ropriate at their 
respectiv^si^s. These site-specific categories formed the^. basis 
for deriving the network standard categories used in Questionnaire II 
* _ > '''' 

w Anr outline of Que^ionnaire I appears as figure V-1, and the ^ 
jfu^l questionnaire i5 ijicluded zX Appendix VI in Volume II o^f this 
♦report. The eight- sections of the questionnaire are discussed below: 

1« Nature and Supply ojE Computing Services - This section 
was intended to ohtairi a description of the hardware .lartd , software 
resources^^^vailable at each site, and any^ constraints and^ conditions 
relative to/iising and charging for these services- It requested 
a de^jKTiption of those facilities which might be cff irtt-^rest and 
available *to outside network users. Questions were also included 
about c-urrent^ practices, and policies relative to adjustments in ' 
capacity and offerings^ ' , - 

. 2. Demand for Cojgputing Services - This section investigated, 

the deraahd for computing services both at present. and in a -potential 

networking, environment. In particular, it x^Q^^^'ted the categoriz- 

^ . - * . * 

*ation ^of users in a way that would be meaningful ^or budget and ^ 

pol:^c^ making decisions. The ^institution was then., asked to provide 

V general profile of the workload^ for each user category" and also 

informatiofi about Usage by job type. Finally, an-.att^pt j^as made 

to_obtain an initial .description of policies x^xi. p^slS^yi^^ge that 

might afffect the way the institution would deal with a/ir^tiojial 

network, , - . * * . ^ » 



Figure V- 1 
Qufe^ t ioimalrte --^ -Qlit 1 i ne 



I'.,- -NATURE AND SUPPLY OF COMPUTUS- SEUVXCES 



A. /-Hardware and Sy-steECLS Software 

B. *' Software. Products/Resources 

1/ Service Offerings - 
2. Constraints on Service Offerings^- <^ 
Prices and^Cfiarging Structure. 
Candidates for use' by Network 4feers 
Supply Practices and Adjustments . • _ 

3Jt Major Modifications in Capa'City or Offerings 

2. Present Utilization and Surplus Capacity 

3. Minor Capacity Modifications * 

4. .Bxternal U^ers - • ; 

5. Capacity Reductions" ^ - 
6* Internal Dedicated Systems ^ 



D. 

E. 



II. DEMAND POR COMPUTING SERVICES 

^ .1' i- . 

User Categories 

'User Characterization . • ^ . " 
Present and Projected Demand by User Categoi^ 
'Present and ^Project^d D.emand^by S^yvice Type^ 
Present Demand by Internar Users for Extei*nal\ Resoi^rces 

F. 'Poten^tiaJ, (latent) Demand: from; Ifaternal Users] 

G. Policy oio: Oytside Usage - *^ ^ * 



A. 
B. 
C. 
D. 
E. 



III. USER SERVICES 



A. Internal .Users - Internal' Facil'ities 

B. External Users - Internal Facilities t ^ 
C» Internal Us ers^ External Facilities , 



IV. ' ORGANIZATION OF COMPUTING ACTl^IXIES 
• INSTITUTION CriARACTERISTICS * 



Vf. BUDGET 



VII, .i' RESOURCE 'SHARING -ARRANGEMENTS' AND POLICIES 



VIII. OTHER 
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3. \ User Services - This incltided tfiose products and/or 
services that enable a user to learn ^£ the existence, char- 
acteristics , suitability, aixd usage, procedures for'computin^ 
services, as well as obtaining help as ne^d^d. Several general 
questi^ohs were included to gathe.r information about this area* 

-•^4, Organizatlcgj^f Computing Activities This section iSss 
designed to provide a feel for t he d ecision ^stfucture and 
responsibilities at* each institution. 

5, Institutio^i^ Characterisrjcs - .Iiiformation was requested^ 
aboi^t the overall nature of the institution - its-, disciplines, 
numbers of faculty and -student^", research orientation, etc/ In* 
most cases these data were provided from existing documentation* 

6* Budget - - Each -institution was requested tQ provide a 

Vsummary: of its overall budget and that part of the budget Allocated 

to Computing activities . Questions were also asked about cost . 

\ recovery policies -so as to grovide a guide to the* relationship 

/between prices charged to users and actual costs. for providing 

the service. ^ , / 

• « ' " * " . 

1 / Resource Shai:ang Arrangements and^ Policies - Each institution 
was asked* about its present participation, if any, in existing ^ " ' 

consortia, cooperative* arrangements, or networking-. * ^ ' 

8* . Other - This op6,n-ended sjection^ asked for infoTrmaTtion ^ 
* on constraints or commitments which might haye an impact on an 
^ institu^^^*^ computing activities but were not*p^^viously described. 
Hiis included such things as state laws or purchasing regulations, 
^ budget limitations, and auxiliary enterprises such as hospitals. 



Questionnaire II 
In 



In Aprils 1976^ a joijit efxort^ )E>f the Stanford Research Insti- 



\ 
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• tute ai?4 the,EDUCOM staff resulted in the second. que^'tionnairajT* 
* It^was ^feveloped ^ter completion of the model design and unlilc^ 



''\the general nature of Questionnaire ly it sought'^ to '"satisfy * 

* ?{)ecific requirements of the model- and the background studies ♦ ; 

Consequently, fecipients were provided with very specific response 

' formats (Tables .to be completed) to facilitate both their 

reSjtbrise to the questions and th^ processing of 'data aft^r the 

questionnaires' *were returned. .Although som^ of the material- was 

^ covered in the first questionjiadre , the response^ to that ' 

document -generally lacked the 'detail that was ^eded to meet Xi/e' • 

requirements of the model. Als^, in responding to the first 

que^stionnaire / not all sites presented data in ^consistent' formats ♦ 
» • * * * 

, ' ^^Quesjibnnaife II was divided inter eight sections, e'ach 
containing a -table or tables for enj:ry of specific qUaijiitati^e 
4ata, The fdjLl ^questiphnair^ is included as- -Appendix fll in Volume 
, II. The eight sections of the questionnaire *were: ^ ' 

* 1/ Resource TypQs and Capabilities * ^ \ ' / 

2. Scheduling Periods and Durations ; . ^ ^ y 

3; Performance Characteristics ^ ' / ' 

•4, Response Time for Interactive" UsS • . " 

5. • Weekly Resource Usage by Service Type • ^ 

• * 

6. Job Distribution by Service 'Type and by Priority 

7. Job Distribution Ijy lJsei;^Categ6ry . 
8'. "Budget ' ' ' ' 




^1« • ResQurce\Jypes aryi Capabilities Each institution was' 
"a^ked to identJify significant billable 'an4/oT .potentially -limiting 
^Yesotirqes and to estimate the usable^ (not- rated) Capacity pei^ hour 
of pach ^of these. Particular care was taken ih defining the ^meaning 
of capac;ity^ For c example, the^. average -hou'riy billable CPU capacity, 
'is typically ;nuch* Ifess than the ma.xi^jjni- number of CPU cycles " , 

delivered in an* hour. Up to^ eight r^souttes^ such as memory, CpU 
utilization^ and output voTume, could be sel*e^ted by ^ach ^site . 
After the Responses were reviewed, it was decided to* designate thp 



six most commonly ^sej.ec ted resouxces, as "standard," Thes^ are: 
'Memory Capaqity, Cards Read, Lines ^Printed, Connect Hour?, -CPU 
Seconds, and l/o^Capacity ^ To this list wa^s added a seventh- ^ 
fetandard Tesourde, Communications Capacity. Although not yet 

a factor at most sites, ^ this ^rea is expected' to be critical in 
a network environment. 

2. 'Scheduling Periods and^ Durations - Si te -;scheAules were ^ 
needed to define' activity and resource availability during the ^^7^ 
weelc. The institutions^ were asked to list the maximum fraction 
oJf eacK;resource available for interactive use ( For -^xampl§^/onl;3 

.part of main memory might be available to' interactive user< 
addition, they were ^asked to provide their, usual daily i>^kvt^mes 

.for batc4i 'aiid interactive work (if different).^ 



^ 3. ^ Ferformanoe Characteristics - In a.net>rt)r 

' * ' ' ' . * X 

all activity might not occur at the same sitey^i-e. 



ent , 

n^i^^nd output 
IS x^^erefore 

s, processing 



W£ 



ng queuemg 
by the user ^ 
to describe crltiCc 

, Th< 



' varioi 



are local, while processing may be scatte^e 
necessary to provide separate Estimates oKinpw^de 
times, transmission times, and output delayXXin 
and other related delays)*. Total tu^aroyd^ as 
is the- sum of all delays. Each s 
input resources ^nd up to three, ^it 
limiting output resource wa-s si>^c 
percents of the effective nrarti 

sites provided the associa^Bd deJJ^Y Those delay tinles were 

requested by type of jobs^ ipi^mity//a time of submission (pea 
or non-peak). Ndn-supn^er/l^ to provide these data fo: 

input and output and Ao in^cat^the average processing time at 
their major source pf supply. 

Y 



essmg resou^ 
a^/the- printer. 
capacity of each resource, th 




4 . Response 



/ 



was tha,t inte 
the average i6imb« 
, asked to p)?6vd<ie/Aabl( 



tatBd assumption for *this questibri 
ctiy^y^e'sp^^e time is primarily a function- of /' 



duals in use. Each site ^was thJlrefof? 
'describing this relationship. 



-9.3 



3 





Weekly Resource Utilization byService Type - After the 
workload (number of jobs' of each service type' offered) is * 
ted by the model, the resource requirement^or each service 
fe used to. calculate total system loa^inj^. In order to 
proyide empirical data ^for these computations, ,the si^t6s were 
requested to provide the total actual usage for' each critical - ' 
resource listed earlier and to /ireak- this total usage down by 
, service type. This provided a /profile, of resource usage for the 
"averagitr job in each service iype.' If a- site chooses a "pricing 
policy Vased on resAirce usage;, the model will be"aSl'e to'cal- 
culate the price per job from the ner job resource requirements 
and the unit price f<^r each critical resourcf. As mentioned, in 
Section IV. Ij/ an adjustment factor for resources which have not*^ 
been included (^11 other") jiust be added, to arrive ehe-^^final^ 
' job cost. Aiyabbreviated sample* of this .table is provided below: 




- / 

* j: 



'A.-' Resource Type * 










\ B. Units 










\. Total Weekly 
^ Capacity 










D. Breakdown jby Service 
Type : * 
■Restricted Resource 
Allocation 






r 




|1. WAXFOR, WATFIV 








/ 


^t. ^ WATBOL •. • . . 










3. PLC i 










4. SPITBOL 


A— 




1 i 


r 

/ 


5. Fast Assemb. (ASSIST) . 

BatchxGeneral 

6. Student FORTRAN 










7. Student COBOL" 








7 


8. Studfent PL! 








[r 


9; Student OTHER 










10. Proe. Dev. FORTRAN 






/ 




-,11. Prog' Dev. COBOL 











/ 



• / 
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, Job Distributicxn Service .type - In order to estimate/ 
' the cost of an average job of each seryice type ^^ith priorities 
taken ijito ^account, the sites^wexe. requested to provide the 
total number of jobs or- cojitiect hours i^er week of each .service 
' type. These totals wer^then broken into the fraction ^t each 
'priority, the fractio;/ at each priority submitted during peak time, 
and the cost of aiy^erage job at e^ch priority . |- A. sample^of th^s 
»table follows; y ^ - . ' • 



/ 

Ser/ice Type 


Jobs 




jori t 




iorit 


r - 


Priority 3 


Pri 


.ority, 4 


Per 
feek 




"Pl 




P2 




r 


P3 


■h 








6. Student FOR'^R.AN 








■r 


















7 . Student. Cv i yi 




-J 




. u 


















8. Student Hi • , 




•| 




u 


















9/ Sua. nt , : { 




-1 


\ 


f 












— 1 






io pjoa. d.-v . loRirur^ * \ 




1 


1 


— r 



















'= fraction of jobs with priority^ 
Pj*= Frac^tioD/of priority i^jobs submitted during^ peak . $ime 



= c^st of aVerage priority i\jobs 



4 



7: ^ Job Distribution 'by User Category - Since many .poli<^ie5 
and budget constraints ate based on a site's perc.eption of its /user 
ca.tegories, it* was necessary tovobtain the. distribution of demand 
for the vaT)ious service ' types ^ovef the insti tption-specif ic user 
categories. For example, externally funded research projects may' be 
alloH^'d access' to the network bat stjjdent instrudtiorial usage may 
not. Af ter« reviev^ng the first" q{iestionnaire^ t,he\projecjt staff " 
developed a tentative set of user dategories. f or-eAch 'Institution 
These were used in the second quest iofinair.e and were generally 
accepted by moiz sites. . The* weekly job (or connect hour) count 
by/ servi ce" type was then distributed oVer the user categories. 



J 



100 



■95- 



/ 



(Note that tMe job count.s by 'service type, should match. thbse of ^ 
^e-,previous table).'. An example of this t&ble is provided below:. 



i 

'/ ■ * ' 
1 * * 


Current 
Demand 


User » . 
'Cat.l 

• 


User . • 
Cat . 2 




iiser ' 
Cat. 10 


• 

6*. Student FORTRAiV 
-A \ 1 












i. Studeipt COBOL ■ , 








• 




Student VI/ \ 

4 ' ' 













S; 



8, Budget - Budget figures provide the data f of 'many of the 
policy decisions and financial reports. The user categfory 
budgets, for .example, indicate potential limits on 5pending. 



" Annual budget amounts were requested including internal ai^d 
external income, expenses such as hardware and software, uspf * 
support > supplies, opexations and programming staff, and admin- ^ 
^. istrati\^e expenses. Estimates of budgets or expenditures for 
each user category for that site were also obtained. 

The data collected by both questionnaires were reviewed fpr ' 

— * 

com|)letene'ss and -Qohsistency before being put into m*achine readable 

form for use by the model, The results of this review is described 
* * • 

in Section V-E. 
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p. BenchroajrJcs . - . 

• • * • • 

^ . *^IInplicit in the concept of networking is ^the need for ^ quali^- 
tative basis for investigating cost a^nd performance differentials 
across a varijpty Okf computing facilities. ThQS^ two areas are 
important since they are among the major, factors influencing * 
Succe5s'.of interr.institutional networking, ' The staff of t^ie^N^twork 
Simulation and Gaming Project worked closely with the staff of 
ano,rher EDUCQM activity, the'Pianni'ng Councilcoi) Counting in * 
Educatioii* and Research,/ in developing 'a jprocedure to quantitatively 



compare -price;* charged a^id/^^JPlources utilized for identical services 

The procedure developed ^f^as based on a set of nine FORTRAN 
benj^hjfiafk programs. Kithiii the constraints of the ^FORTRAN lan^age, 

thi*^ set of programs^ was designed to represent a variety of • 
computing -tasks including' small debug *runs, "number cruhchrng," 
and ^ile processing. A brief description , of each program is given 
in figure V-2- The full s^et of listings and instructions appears 
in Appendix VIII. 

: - 

In order to insure a valid basis for price comparison, the \ 

-conditions under which the programs were run were carefully speci-. 

fied. Three compiler types were identified (student, standard, 

* • * 

and optimizing) and treated- separately. Minimum arithmetic 
precision was specified as 14 decimal digits. Job turnaround Time 
(as a function of priority) was specified such that, on a typica4\ 
day,' there would be at least*" a 90% likelihood that results^ woul'd 
'be in the user's hands >rithin an hour after submission. 



Program Name 

♦ *■ 

TRIVIAL 



• CRUNCHER 

MAIMULI 

• MATMULZ 
CTOD 

t 

I 

PUREIO 
' ARMWHIP 

'^ARMGLIDE 



Figure V-2, ^ 
The Benchmark programs 

' Brief Descript ion 

Does Clearly nothing in order to highlight* job^ 
overhead and minimum charges; / , * 

A loop containing the .four arithmetic operators 
is executed 'one million times.. " ^ * ^ 

Two 60 X 60 matrices are' multiplied fift5r times • 



Two- 221 X 221 matrices "^re myltiplied^once . 



Card-to-disk,. 2, 0(M) datS^^c^rds ap.g'rearf and 10,-006' 
card images are itteit>i^^^s^^V&lly on disk. 

^Disk-reefd, the sequential f ile eated by CTOD 
is accessed and summarized. - 



50, 000/ binary card images are nritten to disk. 

Writes an'd reads' a 20-million-character random- 
•access f il6 npnsequentially .* 

^'riJt6s .and reads a 2^ -mi 11 Jon- character random- 
access file sequentially,.'^ 



'J 
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Since pfjces may differ fiepending on the type^ of user, three 
distinct price schedules were defined. Jat^rn'al pVicas'were defined 
as those that would be charged to an on-campus research 'project 
supported by outside funds. ^ External prices were defined as those 
charged to an educational ^user from an un-af filiated university. 
Wholesale prices were aiso collected, but there was a wide varia-' 
ti^on in definition and griteria for these and they • are> not'^lus- * 

trated in t^is section. • • • . ' . • 

* 

.Figure V-3 pre'seirts several internal price statistics' fgr V 
selected program/compiler coinbiuatfons . Twen-ty-six ins,tallatidns 
were ^'urveyed, but in.sever.al cases' a smaller subset of prices 
wei^e reported. Hardware, software, and administrative constraiivts ' 
precluded execution of some tasks at sojne si'tes.. Entries in the 
bottom* row in the 'table' indie aji«'-the Enormous variation iji pri'Cig' 
for each task --price differentials with ratios as high -as 45.: 1. 
Since the highest, and lowest prices are likely to contain anomalies, 
another comparison was made eliminating the' highest and lowest 15l~ 
of the prices- reported for eac^ task.' Ratios for 'this comparison. ' 
axe sJiown on the next-to-last line and still, range as high as 9 : 1. 
More than one installation does not charge at all<for 'jpbs such as 
.TR^IVIAL,- where the overhead nece'ssary to account for resource usage 
might exceed the resources used by- th'e job. However, it is sur- 
prising, that one installation had .a 'zero pr>ce policy for CRUNCHER, 
which had ah overall average price of $7,571' ' - •\ 

The dollar amounts- repxeserfted in Figure V-3 allow a. compari-^ 
son of individual job prices across installations. However, to 
make a general j:omparison of the prices l:h^t would be charged for 
all research computing or all university computing, .the .composition ' 
of the broader worklc/ad must be known. Qu^H^ta.tive characteriza'- ^ 

-tion of ^ yoxklQRd.ls.,jEi:jSiiX2^^^ Such compa r isofis 

are usually made by taking a sample of acttral Jobs ^and running , 
i:hem at other installations. Because thfs procedure is both costly 
aad time-consuming, it is used only when large purchases are being 
considered. ' * . # , 

'10^ ' ■ ■ ' 
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The syntl^gti'c workload pTocedure'*'de.scribed here provide a 
basis for, comparisoa, with only a moderate' effort. There is some 
' loss inr^ccuracy/ The grocedpre defines a workload or job\jni3t 
•as /a linear ppmbination of the thirteen tasks cited in the bench- 
m'atk survey. ' * , - 



fx- 
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t The pric^ statistics siiown in Figure y-4 are based on a liIfS'ar-^^^^ 
combination of the individual jobs shown in Figures § V-i: ^Xhis 
mix is feit to be representative of the academic workload -at at 
least one/univer^Lity.^ As may be seen in Figure V-4, the workload 
wou^d 'dost an. on-c§ifnpus yser at the lowest-price, facility $^6D..10» \ 
A user with the same workload at the ^highest-priced facility wojul^d < . 
pay $338.96. I If a user.<rould ieird the individual .jrOK's- of ' tbe-worJc - 
load to the facility wit3i the .lowestf price for fea%h job type^ the ^ 
workload price would be $21.62. Of course, a user sending j(^s 
to' several^^ocations would- not necessarily pay internal rates "knd 
would also incur communications costs. , ' * 

• In evaluating any benchmark survey and comparing prices, many 
variables' Biust Ue considered. The choice of taslcs and the use of ' ' 
FORTRAN obviously, introduce bias. . In addition, there are many 
applications that may not be adequately represented by one or a 
, combination of the benchmarks. 'For example , -vthe use of pstckaged 
software sudh as SPSS is written in FORTRAN. Since administrative 
and other ' file processing apj^licationsiwould be more likely ^to use 
PL/1, COBOL,^ a repoft generator, or a data base management sys.tem,. 
administrative applications are nonrepresented well in th4s survey. 
Finally the u5e of interattive computing 'is not 'included in this 
survey, although it is ap inpreasing^ly important mo'tfe of .computing . , 

v^Other differ^ences among installations are important buf'less 
"i- ous * Ideally-^ ^euLl.-costs , incurred in providing €omput*j.ng 
services would be treated in accordance with "generally accepted" 
management accounting practices. Such treatment would improve 
'the comparability of prices; however, important cost components"^ 
such as space and utilities, *are not accounted for in a» Uniform 
way. At least one installation does not include hardware in its 
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cost, base used for cjet^rmining priices, ^ And^ vhen harflyare is ' \\ 
•included, 'the acqUisiti9n cost^ used often reflec3;js stibstautial * 
ven4oT discounts that . are no' longer available. 
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^deral, sttite, and institutional policies also, frequently 
impose unusual c'bnstiraiirjs • For example, a fedeya-1 policy of 
disallowing t^xe cost of ' capital • as- a leg^itiiiiat6 cempqnent ^ 
setting prices for federal contracts shrinks the cost base wjjen 
equipment is purchased rather than leased or. rented. Explicit 
subsidie.s from general university sources, whet4ier these subsidies- 
are planned or the result of .unforeseen deficits, also cotnpouftd 
cost aiwUpricing problems. , _ , ' 

^ . Of the 26 installations surveyed, 20 supplied external as 
, well as internal p'rices. The external price' is defined as the 
price charged t-o an educational use-r not affiliated* with, the uni- 
versity supplying ^the service. In\^ a national computer resource . 
sharing network, remote users, would ordinarily pray external prices*. 
The most common external pricing strategy is a simple percentage 
surcharge on internal prices. Figure V:5 shows the sur.charge 
percentage for the 20 installations reporting external prices. 

It turns out that the ■ installation with the lowest price ' 
shown- in figure V-4 has external * rates identical to internal rates '. 
Any educational uset would thus pay a price of $60.10 for- the 
ijorkload done at that installation. If a user paid external rates 
and split 'up ^the workload by job type 'in order to send jobs to tlje 
installations* with the lowest individual job price, the- price would 
be $25.83 and jobs would ."be, run a't ten diff erent . installations . 
Even' Ipcal* users at the installation with the l,owest overall price ' 
might 'be interested . in the lower individual job prices at other 
installations.' • - ' ' * 

i 

In a mature network it is likely that external prices will 
receive more scrutiny from the sUpply inst'al latio-n and from the user 
External buyers Viil also neeji to consider other costs. The result? 
shown here do not include any commun'ications .cost^ which; if 
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Figure V'?> 

FORTRAN Benchmarks', Intc-rnal Price Statistics 
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1 


18-04 


8.16 


59,10 
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Statistics bv Installation 



Price basis 



Workload 
Price 



Lowes^rice (S) 6U,lj3 
13th Dercenti.L6 price 

. 7.5^.10 
Median price <S) » 127.66 
Mean price(S) .144.82. ^ 

^Sth .percentile-price 

CS) . * 211.46 ^ 

Highest price (S)' 338:96* 
85th percentil^iStn 
« percentile \ , . 2.82 * 
Hi,^hes*tAlowest ^ . 5.64 
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included, >'ould.make chopping for services less ajttf act i ve . In ^ 
•particvflar if a fil.e. of twenty mi Uion characte^rs ^ a<i necessary 
Tor ARMWHip^ajid ARMGLIDE, were shipped Over the network, substantial 
communications costs woxilU be, incurred. Remote users ^ould also fac^ 
additional costs i£ thty needed to suppprt thei'r own user services - 
with/fqr example, documtentation and consulting aids. ' ^ ^ 

- ' - * 

E'. pbserva tions on Data - • • 

1. ^ Ov^rvi_ew - Questionnaire I was verygenerarl and' relatively 
unstructured, whereas' Questionnaire II was very specific in its 
data requests. The responses to both 'represented a wide • range of 
quality and- quantity , Mifch of the data [required fo^ Questionnajlre 
I^coiild be obtainetd ;directl7 from' ^^s^ting 4bcumenty, a!id this. 

; approach was used by m'ost of the respondees. Since the question- 
naire was circulated before the model design was finalized, the " 
survey was primarily intended to provide anroverview -of basic . 
•iii»stitutional facilities , -characteristics , an^^ organisational 
structure. , T^e responses wpre' evaluated for completeness and con^ 
tent, but no attempt, was jnade ^to_ ^f orce consistency across all 
institutions. In ^general the material supplied the. project staff 

. *?ith enough infoi:mS*ti6n tp complete model 'de3igp and to ensure, 
that the inodel'^was capable of representing jnost of^the organiza- 
tions, facilities', and user populations in existence at tlie various 

-network sites. ' • 

; Questionnaire II required perhaps evdh -more effort'on the 
part of th§ participants because the questions were now very'^ 
specific and/detailed. In many cases the data 'were* not readily 
available iu £he.deiired form, if at all. . As with the first 
qufestionnaire,Nthere^ were several in ^tan ceS_in which Mncrti tnt^nrit: 
did not have the data requested but came to the conclusion that 
this was. important management information that should be available • 
Both questionnaires, provided some sites witli .a new viewpoint 
towards data cot^llfection and for othjl^^s proved to be an impetus 
towards the organization of data for . their 'own -use* At least two* 



• # J . * 



institutiptis/haye made sornQjlof^this material a jjeguxar managnement 
reJ>ortijig requirement. , - V 



* 2-:. General Observations ai^ Proble&s - As •meintione^ earlier,* 
the first questionnaire was used primarily ttf -prgtvide the project ' 
' staff with an 'overall view o^X«e Voi^puter ^facilities, offeringf^^ 
, /policies, and deci^fon-maJ^jg processes at 'the participating instd- 
tutions. Most of the following detailed 'discussion will deal with 
.the re.siionses • to J:he^second' ijuestionhaii-e . ^ #• ^ ♦ ' ^ 



'As i^esponseS^ to Questionnaire-,11. wei^^^lH^ffV^'they were 

)ath internal * 




reviewed for completeness and. consistency^ 
and Wth othejr sources of informatioti sucA 



as* tile first'.question- 
naire.^^ Consistency Checks were made to enigure-''that the Irfesource 
capacities'" and ujaits used in the Various^^K>iJT8^were compatible^J^r » 
and that the^ resource prices', resource requiremeji^*^ ejstiiliat^s, 
-billing algorithms, and job, cost estimate^ wete con^iSbtent with -f 
•the total job cost datST Finally #the total resource utilization j 
costs were compared with the total job costs and witk the buS|eted ^ 




^data. Far. almost every questiKinaire, a number, of additional ^ ' 
telephone contacts were needed/ to ^^larify definitions ""and pro- ' 
' cedures and to iron out/-incoBfsistencies . It was a large cpmpli- 
estio^nnaire, ^^nd ^nich work was required to ensure con- 

nd .accuracy. ^ i ' | ' * ^ ,« - ' ^ 

' ^ .J/ / - ^ ' o 

The first major difficulty ericoimterferd ,was that ^ of the murii- 
tude of service types. Many sites were, unable to provide detailed 
/data on such fine job* categorizations 'since, t^e informati'bn re- 
quested was often kept only on an. aggregate level^*(if at>all) ; \. . 
Initial 4>a^kgfound work had reduced the number t>5. proposed service 
types '('OJ^iginally several hundred) to a total of -102, reprissenting 

* 42 major job categories. These , included. 5 high-priorj£ty^ restricted 
batch cj^t^ories suc^^as WATF^V and PLC, 20. glanaral ^Ijatch categories 
^esach haying 4 priorities) and l^^nteractive categories, ,Tl^s 

* set of s^vice types was us^ed in the second questionnaire/.. It ^ j^- 
' quickly bedame clear ,that^ this was still too maHy^**- bqth ffom 

the^-model perspective and for the information Avail able poi«t 



yView. Note that in adddtioji*^ to the Tist used, i.t was. co^isid- 
edr^necesXary to have several mare unasf igried sfeiwice types -fpr 



er 



, unique services. 'After *the rfespolise?^ the se^nd questiOtoiaire | 
.were reviewed, these 102 were further* reduced to>-^^ service types, 
plus 4.. that were reserved .for*"unique service?*. ' - ' 



^ The second, majoV* problei^ was-that 'of ^ata consistency/ Six^e 
it^as left ta each sit^ to. detetmine fhe characteristics * of 'each 
service type a.t their -institution, .there, was no 'guarantee of • 
equivalency over ajl* site^. 'Even within, a site the usage of a • 
particular resource by one service -type did nbt always seem* tcr 
^correlate with the usage by 'another service type. * * • 

In addi^ioiT to inconsistencies in::rthe source dat4, ^two * 
problems were encountered ^in trying to matefi resource and job 
•costs. 'The resources .^^isted did not necessarily include all -of 
the jresources charged for at each insti€li*tion^ due to the maxi- 
mum of eight resource types allowed in'the cmestionnaire, and,' 
in some» cases, to the v^ompl'ixities *of the pricing' algorithms . 
Further, although indiyi'^ual prieing policies for ^resource use * 
were fr^q'uently notilinear, the model assumes linearity.* In- 
each case the' best linear approximation ta the resource cost 
was estimated and used within the simulation model. The effects 
of *^hese approximations was to 'cause differences between the 
listed price and the calculated job costs based on. resource use. 
In most easels the model price wa?^ow because of .the resources 
not i^iti!^^-r^* To .compensate for these irregularities,, a pseudo- 
'resource type called *'other*** was introduced. The value of ."otheqp" 
was calculated for each service type tp bring into balance the ^ 
listed and calculated iQb costs, this was discussed earlier under 
Pricing* (Sectio^j IV^lilV ; .-C , 



^ Afffer all processing steps wer€ qQin^^ted, ^he data were 
conyefted into machi^ readable £<5^. for us>y^^^ the simulation 
model. The approa-ch used is discussed^i.n Appendix III-A in. Volume 
II', Although 'much fe'ffort will stilt- be required during Phase II 
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*to resolve the difficulties, iii^view 



o'f the ycpmplexity of the ^ 



/ problei^ and Compressed time-scale fot thi-s activity the effort 



has been surprisingly, successful 
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VI. 



V. 



A. Overv;iev -and Purpose 



/^^l As stated; elsewhere, in this^report, emphasis in. this Phase 
"I snidy Sfas.(*on constructing andl validating the ba^ic, simulatipn 

-aodel. ■ V%siie II'*'ef forts will f'dcus on capturing, the flavor *bf 
6ach participating. sins titution -V its policies, pr'^ctices., ai^d 
decision^ behavior. Much also remVins.to be. done in the way of 
"tuning" the iiar^wai;^e and wpr^load representations '^o that model 
outputs truly reS^ect- reality (or at' leaS^ jfljat enstitutibnal 
representatives ^)erceive to^ ba reafity) . • i:iearl:f> m^y of the 
more interesting ' experiments with the modelVjnusf. await the com- * 
pletion of th^se^t^sks. It- is not yet possible to make definitive 
statemeilt!5 'About 'the implications ot*particular, policies on spe- , 

^ ciiic sites, y> on th^ impa*tt of network membersjrip on -any re^l • 



^How^yer^ even v^ith tlfe above limitations, ther^ are *i number 
e£ useful tlflngs that can bfe done with ,the model. It is .fully 
operational,^ cap handle any particular combination of policies 
specified, and'ha^^ op-line data files 5,epresenting a number of 
*3.ites. Although the data files require additional validation and 
"tuning" by ;the actual institutions,, they fdo contain complete and 
consj^t^t sets .of data and pdlicie?^* th'at could represent a possibl 

^ ' ■ . ^ f > ' , . • • • ' - - • 

This chafer describes a number of experiments th^ have, been 
ot could be 'compi'ete>-*^itfi^. the model ii) its present' form! As the 
design of tbe model paib^r^Ssed, a fairly oom^prehensive set (/r 
desirable, ejcperimeftts, was specified (Section VI-B), * These art 
all areas tha1^are critical to the understanding of ri^1cjtis;>t\s anjd. 
the likely impacts of netvaxTcs on member institution^ J|Vi though . 
a .detailed ^expei^imental procedure^ was developed for each experiment 
(Sections^ VI^U andDJ, only a\^ubset o^ the list h^s been completed 
Tiiere were several reasons for designing a more comprehensive list. 



of experiineats than was reasonable j:o compete. First, ,the list 
^provides an indication of the ' jcapabjili ties *^nd limitations of the 

model.; I'his was a useful exercise for project personnel in that 

it 5Eofced them to state rather explicitly ju$t what gjoals vrere 
* set forvipie project,, how these goals would be achi^v;ed, and. how 

the *model: c6urd be used -to provide^ the quantitative/ data* -For, 
'non-project readers, it gives a good indication of /the types of r ^ 

results to be expected and the.^level of "xiser** towards which 
(project eiipjxs and model outputs are directed. Perhaps the 
•greatest value derived from d,e^ailing a large' •s-ft' of possible ex- 

pprim^ts was th^t this process verified that t^e exisfxng mode^l 

w'as* capable of .handling them. 

B . ' - Areas of Experlsiental 'Interest ^ 

The selection of ^experiments appropriate Jor £hfe simulation . 
model Was based upon a consideration of the_questions about nef- 
.work operati'on that se^ed to be of major importance. After dis- 
cussions among* the various* members'of the project team, agreement 
was reached on 11 areas< of particular iaierest: 

1» Standard Pe^rformance , - , " 

2. Bilateral Agreements vs. Central Network Organization " 
3*, Sit^ Specialization , * \^ 

'4. iVe^ork Stability' / . . - ^ 

'5. i^etwork Resource Sharing Potential. 

• 6. Commujii cations Costs. ' • ' ^ • 

,1^ Service Pricing. Policies " * - ^ ' ^ * 

Z» , Provision of Special Service^ . 

9. *»etwork ^Equilibrium Conditions 
^, ^ 10. . Quality 'of Network Infonfiatibn Made Available .t-d Users 

.11. Network Growth Effects * ^' 




^ C. Conduc\vof * Exper iment-s * , ^ ^* j 

\ y ^ - * . 

After 'the primary areas of concern Were identified,' attention 

was directed 'toward the specification of appropriate experiments , 

within each of th^^ areas • Most of the experiments weJre li^it^d ^ 

to/ 22 time periods and were run with five sites as described in 

Section D-i. The number of sites and time, periods was arbitrary for 
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.experiiaental purposes, and more could have been used/ These 
choices were based on a dfsigre t5 minimize ?-iin costs at thi6 ' 
time* ♦ As tjie experimental results iadicate, there were consider- 
able network flows even with only five .sites and less than six" 
months of simulated time. ' . * . ^ 

• ^ ^ . ' . i % / . 

Laph fexperiment war conducted by ch^'nging the ^appropriate 

daita files for each of the five sites to reflect the policy ateas_ 
or supply offerings under investigation. Occasionally, a Separate- 

subroutine was written to model unique situations/. ' In the, shoclc 
experiment, fpr example,^ a modification to routine XOGEN <3*1) - " ; 
was written, which made site 3 unavailable as supplier in 
period 10 'and -avauiiable once again in period 11.' vThis'>fa5 accoiff- 
^plished with nine lines of FORTRAN code and demo^ts^xated the flex- 
ibility of the model, and the ease, with which such additiqjis can 
be made.N ^ . ^ , 

. Although it is expected that inVg^real network tife "^tabili * 

zation pf network flows will«tak^ a long timre, it was possible 

♦ • 

in the experiments to select jpolities that hastened this process 
so that most shifting had b^en completed by week 10. Several of 
thi experiments required that perturbations be made to a stable 
network, so these runs were, carried out^bver a piei^iod of 22 we€^s ^ 
(with the perturbations occuring in week*10) to allow observatioir 
of the effects' of .these perturbations. . 



Experimental Ryns 
1. Standard Performance 



1 ^ ' 



£.xperiment - Th^^ major intent of this experiment 
was to determine a "ba^se" performance level' to 
serve as' a standard of - comparison for the performance 
data derived from snibsequentoexpelrimental runs* 
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The standard run on which comparisons were .based. 
.If . ^ 

reflected an idealized environment in which all wQrIc 
qould be*done (i£ desired} at any network supplier, 
nardware incompatibilities, conversion costs., uelays, 
and network surcharges were ignored.. The common 
preference to do' work -"in-nouse** i£ possible, was, W 
reflected by gi%^ing each site -a 20% internal rating ' 
boost as compared with outside suppliers^ Similarly, 



the problems involved in switching suppliers^f^r§^ 
repres^ented by a corresponddng*^teting boost* iii'^SVol'^ 
of the preseixt supplier. In order to better exa^jine 
the potential for network usa^e, it was assuigied that^ 
none of the sites put artificial restrictions 'oif^^ 
where' or how users^spend available ^funds. ^ 

."Results ' -The opnf i^guration of the five sites ^used 
in this and the following simulation sttidies were ^ . 
as follows:^ . - _ . • „ 

Site * DescrijJtion 

Site-l 'IBM 370/158 medium load 

Site- 2 IBM 370/145 heavily loaded 

Site-3^ ' IBM 370/168 ,ligh*tly ^Loaded 

Site-4 Nd internal hardware. Only 

interactive demand which ^'s 
* ' \ ^currently satisfied' externally 

^ • from a iion-network site. 

Site'-S , H6l«1) - large, time'sharing 

s^sftem. Extremely I/O 
i . , bouutl. Specialized user ^' 

GoimiSunity that does not ■ ^ 
, have Sny batch usage. 



ie^5 



In the base run, sites 1 and 2 quickly became heSVy 
jietwork user,si site 3 received. a ;iarge amount of. 
vwork from the network (both batch and interactive) ; 
ysite 4 shifted approximately 101 of its demand 'to 

the network; whil-e site 5 (after raisiijg I/O charges) 
' sent much <?f its I/O bound i^nteractive work 'to site ~ 



r 



/•S^ and received a large> amount of in^teaXctive >rorlc 
c ^ frcHtt other users on the network. ' Figute VI-1 shov^. 
*the cumulative 'dollar flows at period 20. '0£-^t|ife , 
total $4,028,694 spent by the users at th^ dif- * 
ferent 'sites, almost 13% was.^pent on the network. . 
. Xt. should -be noted that site' 2 shifted almost 
704* of it^ "total ^jq>endijtirre& Wto' the ne^ork. 

» ' - ' • ^/ 

' Figure VI -1 . 

Cumulative Dollar Flows - Sta(ndap/Rim (20 weeks) 

. Total User * " Network , Network ' Balaiice of 
■ Expenses Expenses Income Trade . 

Site 1 . $ 545,761 $168,444 ' ■% 57,539\- $-110,9^5. 

Site 2 400,662 271,937 - .1,484 -270,433' 

Site 3 1^076,605 , 9,079 314,993' , 305,914, 

Site 4 332,154 • .33,948 r ■ q - - .33r,948 

Site 5 1, 673,508 29,690 138,982 ' U09,5'92 , 

$4,028,694 $513,098 $513,098 - . % 0 



2-. BilaWral Agreeaentg vs. Central Network Organization . 

V 

' a. Experiment - This study ifivestlgated some of th% 

effects of a central organiz.^tioij which would facili-- 
. - tate usage of multiple sites by a remote user. *^^or 
example, .such 4 central organization might provide 
account numbers., for mu35tiple-f^cility use, .central 
' billing services, and standardization (or autoinatip 
^ translation) of job control set-ups and procedures 

^at eagh site. The alternative to having such a /central , 
organization would be to rely upon^a series of ^ilateral 
V agreements between various institutions on the network. 

It was felt /that the central organization would facili- 
tate, use of multiple sites by users btrt that- the ceiP- 

't^al organization might also require some type of 

\ 

surcharge "in order to support th^ Services it Would . 
provide. ■ ■ 

-Ill- ■ , 



V 



^ : 



The positive effects of *a mature multilatera^l network , 
were represented by"^ setting_DEBUMP,> the -in-uouse 
pating increase factor, to^'l.O rather. than 1.2 to 
reduce the favoring of* in- house usage; KDP, the mbmeji- 
turn factor, was set to a low value so that .demanders j 
did not have a great allegiance to the site\ where ^ 
they were currently doing their computing." Us' an 
initial exp^eriment; np surcharges w^re impos^pd. 

• : ■ \ ■ 

Results - TEe most noticeabl/ behavior obser-^Hed in 
these experiments was the large ^iercentage of ; inter- ' 
active work on the network. Within 2-2 weeks ^ 33^ ' ^ 
of all interactive work was being satisfied oji the* 
network; In addition to the interactive usage, 161 
of the batch j9bs were sent over the networks' This 
was a surprisingly high percentage* ..considering 
communications, costs associated with batch network ^ 
work. As^ might be expected, most of the batc'h' f lo;*s 
were directed to site 3', the ,3^^168, By week 20/ ^ 
siteC^ was "receiving almost as much income from^ network 
users as it was from its inside users. Site-S, heSvi*- 
ly loaded at the beginning of tlje"ran, quickly became 
completely s-aturated. As the prices of it? overloaded 
1/p channel were increased and ^^naround -became in- / 

'tolerable, m^ny „of its' I/O intensive users mov.ed to- k^ 
site 3 to avoid the higher prices, uver a lofiger 
time period, eitlier the I/f) capacity at site 5 .T^ojuld^-^ 

'be increased to accommodate^ the demand of much of>$fche 
usage' would have X6 be discpuraged. ~ 

Because of the present lack ot understanding of factors 
influencing shifts of workload {pcfiicies, -user behavior 
etc.)>-i^t is dangerous "to An t much cate4enqe, in the 
above results other than to rjscognize that^,"' given pres- 
ent price and service levels, ^a $.ignificant percentage 
of users might be willing ;to ^ somei^erfe- else. " 



Similar experiments wppThigher communications costs^ 
indicate that a nominal surcharge for the central , 
facilitating function' would not be a major factor in 
networ^^ usage*. CCExperiments should be run to deter- . 
mine the point where sur6harges womld* begin to affebt 

flQ'Vs). _ .*■.-•• 



Site Specialization ' ' * 

-a. Experiment - The primaS'y intent "of this area was to 
,-investiga^tft the ef fects^ of site speciali;sation in 
- •such services as low price, user support, or rapid 
turnarpund. The questions to^^be answered concerned 
the viability o^ centers that try to specialize in s 
this fallen/ and the .types of user response to thes'e 
' services For , instance, if a sit^ e&pliasized those 
seryice typ^s that a^ere efficient on. its particular 
hardware,* it cou^d charge less for. these service types^ 
than a site with a comparable hardware conf iguratiSri 
but which offered a -full-grange pi services.. By- spe- 

^ t 4 

cializing in the^services it offers, a site can also 
focus on the hardware* configuration necessary to 
. support those services. \ i^ 

one im^ication of site specialization is the shifting 
of usage of some service types t5 ot,lrer network sites 
that process them^ comparatively more efficiently. 
JPu5t as in an international trade situation, where - 
different countries have different mixes , of ^aw ma- 
terials available to them, and hence trade between . 
them becomes beneficial, so, in a networking situation^ 
pne' X0UI4 anticipate certain, service type^s to floK to , 
^ 'particular site^j^which liave a comparative, advantage 
\ tfiat "type ^o-f computing* Thus in ^ networking situ- 

/ation, one migl^t^expect that the distribution of ^ 
service types processed at a site would change over 
^ ^ ' time, as users: moved away from thit site and onto the 




network, for selected s^^rvice types. \ At the. same time, 



users fjbm the network sh'otLid, on balance, be expected 
to become users at that site' for tlie services which / 
it did provide efficiently. If this phenomenon occurred 
Tifare.>iork could.be done on the networjc than tzould be 
" done at the sites individually without aiiy increase 
in resouVcesI ' . , ' 

b. results - Although^^separate exp^ri-ment-al runs were 
, not made in this area., observations bn site specialri- 
^Matdon w^re maxi^ in a number^ of the otiier exprerir- - 
* * 'feents'. Every installation had some us^rs going onto 
the network for at l^st paiyt of ^their needs, and 
• every site that off e'r'ed services 'found some- outside 
- buyers for some of their 'serviceis . 

Site specializaticxn depends to 4 great extent on 
user behayiopr and policy decisions. As .these aspects 
are developed moVe in Phase 11 and a wide selection 
of polic?6s b'^come available, this topic will be more 
thoroughly inv^estigated. . ^ \ ' - , 

Network Stability ' ' ^ V, ^ ' 

a.^ Experimenj^ - Ihe majqr ques'tions to be answered in 
V the area of network stability concern the Conditions 
/Under which* institutional behavior will become un- 
^:^t;9ble and lead jEo wild swings in use of the netwo^ 
Typical factors ' that might iead to this^^ condition 
include; ^ - . 



• lowered barriers to iswivtching 

# price- competitiveness among networir~sites 
.# .shifts .in behavior patterhs \ 





capacity shocks 



Lowered^ bari'iers to Jhe switching o£ suppliers wiM 
evolve from technological advances .(^^sier technical' 
access)6and a central facilitating 'organization. 
Various levels can easily bfe represented in the model 



by adjiis ting ' the momentum pa»xam0ter which governs the 

tendency of users to switch site's. As this value i^ 

decreased, users will find it easier- to switch sites^ 

Thus, when difficulties occur at one site, there will 

be a tendency to have a mass exodus of lisers to * \ 

either, sites. This switch could, in itself., cause 

problems at the new sUpplieT sites (i^e., overloading) 

which would encourage eVen more moyement, A number 

of experiments could be conduct^ed exa^ning network 

^behavior as this momentum parameter is varied. Special 

circumstances could induce instability even in. normal 

circumstances. For example, an artificial shock*^ 

whic^* temporarily inducerd poor turnaround at several 

s might trigger such a reaction. 

* * • / 

-A variety of price cutting situations could also 
caus^e abnormal network flows.. Suppose, for example^, 
an underrutilized site is successful in attracting* * 
work -by virt^ of a Series of R;tice .reductions . 
if varying numbers of other«s<£tes r6^pon<L^n\kind 
What if stiil oth^r sites join in the comfl4,tix(iori? 
What if selected larger.*slte§ act ^in a j^r 
ner? " ' " • \ ' * * ,\\\ 




What 



In the behavior .area, shocks introduced^ by 
shifting to entrepreneurial behavior, to,'|ze!r 
balancing behat'ior, or to cest minimi zat ion-' b 
tould createrinstability *rithin the network., 
of sites 1i|n<r^ possible behavior^patterns alio- 
range 6i ^pei4mentatioii in this area. 



A. 



havior 
li^timber 
wide i 



A netifork in equilibriVi could be vulnerable to^ a 
variety of perturbations in available cai5acity. "Typica^l 
examples might include the addition of a hew i(etwork ^^ 



supplier offering a ^bs^antial portion of networ 



; the addition. of a new net- 



"capacity at reduced, pi;ice 
work demand source having 1 a^emand eqiial to a si^nifi- 



» 
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site 1, which still* had some excess, capacity All 
v-of their work was? acCommodatedV albeit, soiriewhat slower* 

- ' ^ . .. ■- r 

No <>3cillatory behavior developed with this' particular , 
shock, j'iost of . the users returned to site 3 rather 
. quickly since, on .balance/ i€s^ offerings were signifi- 
cantly more attractivjg 'than, available aLternativQs/ ' 

A similar experiment 'was ^to' unexp6(itedl^ reduce the. 
Supply at. site 3 to a sma 1,1 percentage^ o^ its normal* 
value, thereby silhilating- a week of excessive, unan- ' *^ 
ticipate<i 'down- time. In this case, users sti3.1 at- 
tempted, to go there, but tTier^ was a large amount 
of unsatisfied demand. In addition, sit^ 3^ turnarounds 
*- became intolerably high. As'one woul'd exp^ect, in the' 
weeks following the shock, many tiyrnaround- sensitive ' * 
users* moved from site 3 to other sites...-<Jif the network/ 



Xhese simulation runs indicate tWt in this repre- 
^ sentation, tfie network is quite ^^table. There are a * 
nurabei' of factors that tend to dainpen movement ♦ These- 
include communications -limits*, in^r^a^ed turnaround 
times, and. site capacities, After^ site ppLicies and- 
decision-mailing rules have been ^fuVthfer refined, the ^ 
area of network stability can be explored in more detail 

: ' - 1 . ■ - ■ • 

Network Resource ShaAivg Potential, 



a. Experiment -'A major, question conceirns 
sharing which can take place unde'Y 
mental conditions. -The ty^^j^of ' 



'^th'e degree of 
varioitS. environ- 



/could be tested include; 



3^ 



conditions that 



t. Situations in which there is a \iide spread ^in , the ^ 
service type costs offered by the different facili^ 
ties, .providing users with econqmic incentives to 
share resources. 



^ 
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Situations in which there \s, a wide spread* in 
turnaround' time between service types and between 
different sites on the network, jjroviding the user 
with a response incentive td share re*sources^ 

Situations in which different sites spejdialize "in 
different typ6s of .services, giving the user a 
service incentive to share resources. 



t Situations in which the external price of services 
is perceived by all users to be less on the iiet- • 
work than it is at their lo^al site'^ i^rpviding . ' 
ahother type of economic incentive tfa, move onto 
the network. * ^ ' *\ ^^ 

• Situations in whi^rh , t^iere are no communications 
costs, reducing an economic barrier to sharing. 

Results r All of £he above conditions were tested 
during the simulation funs.- Most of the results . 
Were as' expected and will not be detailed here. 
In general, users moved from one site"to another 
based on major imbalanc/es in an,y of the following 
' /-^reas : price, turnaround, or support. ^ l- 

Communications ' Costs 
a. Experimd^nt - In considering a national network^ one 



I of the ^prime questions to be answered, concerns the 
point at which communications, cost will begin to 
affect the volume ^of network traffic* Ijt i's also 
important to detemine the typ^s of users or* services 
which would feel the impacit first. 

b. ^ Results V- The' effect of communications'^costs *was 
, . studied by varying communications j::osts over^ a range 
from, zero to $50 .per ^ilo-packet^- (In certiain situ- 
atjlons, curren^ prices arfe approximately $/60/kilo-, 

s . packet) . . . 



Surprisingly, tfiei:e were reas 
high communications costs. 



onable- flows even for ' 
orte run, with communi- 



"i'?'^ ' , - cations, co6ts set at $3/lcilo-packet, 14% 'of the batch 



work and 21t the interactive work w4s done on the 
network, Apparently^.-the high prjlce differentials 
r / , that^exist between sites can outweigh *s€^n{ingly. high 

^'}. coinmunication costs* When cDtemunications C9%t5 are" f**-./ 

reduced to very ^ low values, network usage ijicre^s^es 
evdn more% as an -increasing nu]^^^__^ service typ'e^ 
^become less expensive at othei? sites T ^ ' ' * 

_ It- should also be noted! .That conrniunitktions co&ts. ' - ' ' 
dramatically impactefd the ,type of . work done over the 
'npt^ork. rtlien costs j^ere high network usage was 
priijarily devot'ed to s^ervice types 'that generated } 
r-elatively little network input* or output-. As com- ^ 
munications c*harges dropped, more communications- 7 - 
. intensive service types became economical to do o'iFer . 
the network. As an example, when communication costs 
were in 'the range of $10/kilo-packet, site 1 only senf < 
I jobs from three different serSdce types to site 2* 
When cos t^' had drop^6d to $. 0"S/kila- packet , site* 1 
sent 21 different services .types to sit6'2. Flows ' 
in the reverse direction w^nt from 10 different, ^ ^ 
service types to 21 different servtte types as communi- * * * 
datioiis costs were lowered. 
' - • 

Lowering communications cpsts appears to broaden the ^ ^ 
' ^ types of work done via the network,. Most of the in- 
creased flows appear to be from the /increasing number 
^of different service types for which there. are network 
. • flows rather than, from increases in already- existing 

service types due to 'direct pricp impact. .-^ ^ 

7 . . Service Pricing Policies ^ . ' - ^ 

^ • : . ■ ' ■ • . ' • ■ . 

9. Experiment - In a cooperative network Composed of 

independent .institi^lons, there are important j:^uestions , 
concerning the .impact of sites using different types''' 
of pricing strategies. Foi* example, what is^ the 
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iippact of ^ facility that vseeks to be competitive, 
that seeks to base' prices ooily on ' cost recovery , or 
thatr s'eek^ to^l^ase prices pn_cost recovery plus prof itt;'^^'^ 
Most of the data on network behavdor under different 
pricing conditions c^ be obtained from the runs ^ 
associated, with^etwork Stability {relating, to prite^- • 
and capacity) and those. on Network Equilibrium 
Conditions (relatliig to entrepreneurial behavierr) . 



fe. Results 



The initial ex;perimentai results on pricing 

policies focuses on policies in which sites priced in* 
order to- maximize j^esburce utilisation. 



Sites 1, 3, 

and S^all followed an automatic. pricing policy that 
lowered^ resource prices on resources that were (greatly) 
upder-utilized,, and Raised prices oii resources that 
^^j^re^ (greatly) over -utilized. Considering only two 
resources^ CPU antTTT^ site 5 tripled its I/O prices 
-during a typical • run:, while site 3 lowered its I/O 
prices »by" appro^cimately 25%. .These resource price 
^changes for these* two resources affected the per-unit 
price o£ all service types. Of course, ^the price 
changes weore' reflected more directly to users who 
use service types that were* intensive in the use of ., 
the resource in question,; At both sites the policies 
had th9 desired effect. I/O intensive jobs migrated 
* away from site 5, thus^enabliiig the facility, to 
increase its total number of jobs, Similarly.,^ite :r 
3 attracted mu(!^new wo^k to its facility duetto its • 
price reduction. ' ^ - ' ^ - 



* ' ^ ' \ w * 

'.1^. i>rovdsion o f Special Services - Possible Experiments ^ - In' 

— 7- ' '^^ ' - I • \ ~ 

the'ajrea, of special services there a)re^ a- number o\ questions to » ^ 
"* . . . . ^ . . < ' ^ . ^ - T • . * * ' ' ' . 

which answer? are sought, incliiding the ability to teward ejitre- 

'preneurial risk (investment in the development of such services) ' 

through surcharges on the use of these special services. H the 
' » /" «* • • . 

'network is. to have, a means of encouraging the development and support 

^ ' *' ' •/ ^ ^ . * * 

* of new services *and spe;:iali2ed software, it may be necessarj? to . 

.-, . ■ -, - ■ " 
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Hiv6 some, sort oi surcha^e or royalty arrangement/ Thus far^ the 
absence of reasonable estimates of demand or response patterns for . 
new;,iervdees .lias limited experimenrts jln this. area. This type of 
e%erimjefit^ is particularly well suited, to the gaming phase, of th^*. 
project -in JWhich .users can react directly to such offerings* j . . f 

One tlse/ul set of experiments might assume several reasonable 
(possible) demand patterns. For each pattern^ runs could be made^. 
tinder the assumption that ^there is no impact upon demancl o^ various 
levels ^of sjurcharge. yHence, the u^ihrndered growth pattern of .the 
demand for a new -service could be examined over time. From this ^ 
rcbuld be calculated the revenue pattern ov.er time that ^rould result 
at various levels of royalty. Ihis revenue' pattern would be an 
optimistic one,, but would serve as basis for comparison with devel- 
opmoqjt %pd support costs for these services. Following this, a • 
set of runs should be made to look at the^ impact of various l,eveliB 
(^nd types of surcharges on demand. Thus, runs might be made with 



'a range of surcharges, starting near zei^ and continuing until a 

surcharge was reached that would choke off demand faster than 

' > ^ ' ^ * ^ * 

revenue would increase. . , ^ . 

, '* ^^^^^^^ 

9. Network-^Equilibrium Qpnditions ■ Possible Experiments - An , 

-important , set of questions tp be answered about the network concerns 

The characterislLics that the network might have when it reaches a 

stable equilibrium cbnd^itipn. The' particular types of site^behav- 

ior patterns to consider might include: ' ' 

• • • * 

# Entreprejieurial - Th^ computer operation as an "empire 
builder." . • - . . 

♦ zero net balance of trade^ - Jhe expenditure^ of the facility*? 
local customers on o^side services is to be appjxaj^fmately * 
equal to the expenditures of outside networ^,-ij«r|rs at the 

^ local facility. ' ^ \ - , ' . \ 

T ^ # No capacity increase - The computer facility does not in--- 
- crease its processing • capability. when full capacity, is' - 
reached. . - - . ^ 

Delayed capacity increase - The computer facility adds 
* services or capacity only a'ftej:^ the additional demand has 



\ 
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^ beetf ^'assured," lead#ig to a lag, be.tween the reachiijg of 
„ ^ - capa2?ty operations and. the acq\iisition, of ' additional ' 
: ^^-pxdcessing papaijilit^:. i y ^ 

\ ^\ . ^ • . ^ ^ . . , "^L ' 

• gost minimization - 'Users ar^^ encouraged to t^e advantage 
6f . the' niost ; Economical sources of supply over , the networlc 
- V (includijLng'in-house) ♦ The, facility reducqSy capacity if 
necessary' in order to inatcK its. supply of services with . 
. , iDcai demand* * ' / . *' " " 

^ : .■ ■ .\' ■ ' . . 

•X. 

Sfte specialization - The facility specializes in some 
pai^ticular c^ability such as #ow-priced service > rapid " ' 
c ^turnaround J of user support. * / * c> 

The basic experimental pattern would be a set of. simulation 

runs that would test varying "numbers of network sites exhibiting 

the partiGsjLilar behavior. Thus runs might Jje planned wi^th one site, 

- 50% of the^^ sites* and all of the sites exhibiting entrepreneurial 

behavior ♦ Similarly, ct set of runs could be made with' aj^ying 

numbe|^of sites, exhibiting no capacity increase behavior, zeilo nelt 

balance behav^br, and cost minimization behavior ♦ In the case of 

delayed capacity, increase behavior, two sets of ^uns would be re- 

quired* pie first sef of runs would involve a varying number of 

*' — ' % ' . * * V 

sites exhibiTlng moderate lags between the^ time capacity is reacKejd 

- * If-* « ' 

^ and the time^additional prrocessiiig capabf^lity is installed,* while 
the second ^et would involve. a varying number of sites having ab- 
noreally loftg lags' between the time capacity is reached and the 
timB- additional processing capability is installed. ^ , 

_ ' Site specialization experiments present, a^.more complex problem* 
Eir^t, aj. series of runs should be made with-^only one site specializing 
in low price, rapid turnaround, user support,. or a special setvice , 
typer Tlien a set of runs .can be made with a varying number of sites • 
^ (e.g.., -50%, X00%) having the same specialty* . If the runs made witl) 
a single spet:iaUiziijg.^.4i^e indicated different behaviors or diffe'nent 
equilibria ^bipg reached as a function of the type i>f specialisation 
(e,gj| low price) y then i^ will be necessary to replicate the runs 
(with varyinjE^ntimbers of specializing sites) for each o^^^he different 
t^pes of 'Specialties * Following the examination of sites having . 
^the same speciaj^ty, it will be necessary to experiment with varying 



/ 
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W^yexSsOf sxt^s /Having differ.ent Specialties to see if a balance 
in types. of specialties* of$BTed^has any impact onfthe equilibrium 
ireached by the nepfiork. " ^' . . f ' 



•'*a.' Experimental Results -^^gtfhduct of 'the full experiment 
7 . ^tPuld involvB a larg^ number of simulation runs* Ho*-«^ 
ever, many of the splecific^ questions can be examined 
byanaJLyzing existing data from dtlier experiments^* 

1) Empire Builder - In most of the simulation experri-,- 
. /.pents run, site 3 has many of the characteristics 
of all empire builder* It-is lowering its prices 
to try to build up demand. Vi has high suppo^tt "for / 
most service types ^ and it clearly has much mor>\ 
capacity than it needs. This behavior was rewarded 
in all' of the simulation experiments* Site 5 con- 
sistently showed a net surplus from. its networi; \ 
usage\ and it quickly took over "a significant amount 
^ of the interactive work on the network. Future ex- 

periments will have to Ipok more carefully at the J ^ 
situation in which there are multiple sites exhibiting 
this behavior pattern. ^ * 



2) Zero - Net^^ Balance - Several jruns were made to investi- 
gate site behavior under zero net balan<*e of ;tfade 
policies. The results were largely a function of 
the cpmposition of the networfc. If ,the network con--- 
tained a large percentage of demand -only ^sites, for 
exampde^ ^then zero net ^>alaiice-of trax^e^ res prict ions 

• at particular sites had little effect on aggregate 
network flows. ^ Oh the >the^ hand,, if all* sites on 
th^ network were suppliers foriowimg a zeifo net 

' b*alance of'-trade policy, growth was ,slow ai;id oscilla- 



tory. Some sites with little to offer eventually- 

^ - . ; . - ' ' t 

withdrew from network participaticfa. TKe general 
conclusion is that siti^s with desirable searvice 
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^ off erijigs /(ev.fn if oi^ly a few) are able to follow this 
• - policy with 14 tt_le difficulty. Most others are C 

» r.. ' * . "successful ipnlV^^i^ there exists a ^easoxiable number ..^ 
"' ^ <if sites -that ktb^ net demandera of services.- 

^ : ■" J. • ' , , ■ ^ ' ■ ' ' '> 

^ ' . . Quality of Network Information Made Avail ahi"^ to-USers 

_ The or questions in this area concern the effects that 't^e 

. quality 'of price^ turnarpund , 'and suppar.t information can havte on .* 
user beT^yior and how the behavioral-. changes relate to the- expense 
•of, providing various qualities of status infonaation. ' 

• ■ ■ / ' . . 

• ^ . - • - 

i ^ ('The necessary information can be derived f.i^/a set 'of experi- 
mental' runs with l^arying 'types of aieftwork peri^^nce" inform ation ^ 
provi^d to user3-r~^These inCTude perfect information^ perfect infor- 

lags,, and information Laving varying degrees of 
#^ randomized distortion as well as bias. 



fl- Network Growth Effects .'- A very interesting area conterns" 
fhe po'teiitial that th6 network has for growth by.net service de- ' 
m^ders joining the netwcfrk. Of particular jconcern are the effects 
that such additiona.l demanders can h^ve upon the suppliers, and upon 
the behavior of the [^individual network users. . 

', • ' • ^ ' "~l . > 

'JIuGh of tjie^ta desired^o^v-^his ^rea will bjs obtained from 

the capacity experiments conducted a's a. -part of the netwo'Kk stability 

tests discussed' earlier^ Ho^^ever, if'would.be desirable to ..make 'a . 

limited number of additional runs with very large net increases in 

- network demand (e.g., sai, 1001). These runs should- |>rbvide an 
indication of what teight result if a number, of sn^ll , non-supplier 
sites ^or ^a larger site with inadequate internal capacity) were to ' 
join the netwbrk. They wouW also provide an, indication- of the way 

^ in wfiich the perturbations caused by the increased demand would 
.■work themselves "out. * , 



h* , Stnninary of Fiiidings 

' * ? ' . ' ' ' - 

As stated, 'the experiments thus far ire of a very preliminary ^ . , 

nature and ft is dangerous to draw many hard conclusions 'before 

a full set' of institutional behaviors and policies can be incorptk-ated. 
However, a number of interesting .trends -were demonstrated that 
bear further iilVestigationc The experimental results have the 
following implications for the' viability of an ^ctual institutional 
network: \ - , * 

1. ' Netwoil FloHs ' - Substantial forces exist encouraging net- 
work flows. There ire large discrepancies among sites on the net- 
work in the area, of prices, turnaround, and' user support. Assuming"' 
'^that site hardware costs are not incresrsed or decreased (in 0ie ^ 

^^jhor€ run), one wouJLd expect the average price -pe r job to dprrf^aQ*:. - 

>i^ificantly in a network environment.^ In. addition, -avterage job 
Hurnaround would decrease, and average support levels pel job would 
increase. The major inhibition to network flows would 'J^ policies 
through which sites attempt to-prevent their users from using the 
network because -of a cash flow drain. This deterrent would be 
greatly reduced if there were a reasonable number of sites-'that were 
n^^t-demanders in-balancq; so that all supplying sites could attract 
ii^ome to help support their network usage. ' . 

_ -2. Network- Stability - Non?; of the simulated runs this far ' 
exhibited unstable behavior -even in the presence of ^^latively 
large shocks. Therp seem< to be a number of stablizing factors 
which contribute to dampen oscillatory movement and the implication 
15 that the,-netw6rk is quite stable 'in. its current representation. 

* I 

% 

^ • " - 

3. ' Communications- Costs - Communications costs .do not appear 
to be a significant da^t^rrent to network usage' due to the large 
discrepancy &mong sites' current prices. Hokever, it is unlikely 
that price dif fe^ejitials as large as those that presently exist 
would remain An a real network environment. Hence, flows would be^ 
less than reported *^'ere and the sensitivity to commfunications costs 
would be correspondingly larger. 

\ .. . 



Central Facilitating Network -It appears that the potential 
exists for a positive role for a central facilitating organjization. 
A facilitating oitganization should encourage efficient use of the • 
^network, and should, ^ilve somf method of funding. T& simulations 
indicate that Both' of these conditions appear' to be true. .First, 
the multilateral simulations showed considerftly more flows' than 
the bilatsral runs; and, second, the communications costs experiments, 
indicated 'that a surcharge on network traffic could- be used to 
finance a central facilitating organization.' « % 

As the policies and site behavior are enriched in Phase JJ, 
the wide selection that will be available will allow even further 
experiments • Some of those that have already been done caA be 
e^anded and examined in more detai^l and those that were only out- 
lined liere can be performed* Thus, through such^,set of "experiments" 
more can be learned about the implication of various policies and 
behavior patterns on both th& participating institutions and the • 
network. 
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j ^Tll. SUMMARif OF PROJECT STATUS 

♦ 

• "1. , — 

'V ' - . ' . 

The ptf^pose .of this section is to provide' an abbreviated 
^srfip'tion of the project ^ its current s,tatus, and plans for 
Phases II and III. ' ^-r^ 

. •' * • -• ^ - • . . 

A.^ Sidnulation Model. • ' ^ " ' 

, f \. Characteristics- ; ' • 

• Is designed with a modular-^tructur-e a top-down 
fashion.. f ' 

f Penaits relatively easy (often trivially so) insertion 
of new modules and modifications to existing modules ♦ 

^ • written an FORTRAN for' maximum' transportability 

• Follows we/l-defined .conventions to increase readability, 
' • .avoid errors, and simplify maintenance . 

'* • ' . 

^ * . Operates with a weekly time interval. * 

Incorporates a wide fange of decision variables that I 
permit the exploration of" policy alternatives. ^ 

,# Define!s computing services in terms of (currently) 
44 dj.ff6rent standard "service' types" whichr are 
relatively homogeneous services, such ^s "debugging 
runs" and '^short statistical packages." 

• Pennits each site to define (currently) four special 
service types that are unique to fhat site and of 
general interest to outside^ users'/ 

% Defines capacity at ^ach network site in tem^^^f 
seven stand^ard basic resources stij± as' CPU speed 
and primary memory size and one Optional resource 
which may' be selected by "the site. * . 

* ^ . ■ ' 

• Estimates for each^ time increment, the demand"" at 

^ each site for each service type* . ^ •> 

• Maps s^rvic^ types into requirements for each r^sourcgT 

• Determines actual demand at asite by aggregating 
demands from tfll sites (including local demand) and, 

. then accounts for constraints on cash flows, communi- 
cation capacity, etp. - r 
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2n Status 

' • Is currently, operational; 1 



• Cftntains approxi4ately 15,000 -isource. statements • 
(1/3 executable statements, ,.1/3 noV-executable 
statements, e,g,,*^data definitions, ^/3 comments). 

• Is thoroughly "documented. 

' Has-been validated and is capable, of .performing a34 

specified analyses. t - * "^-.^^ ' — ^ >-_-^^.-_ 

• Requires expansion'^f the lihrary .^of avMlable poli- 
cies and practices^ minor task continuing throu^oat 
the project. ^ - ^ / ^ . 

. - . : ^ . . • > ' ^ 

# • Kiqujlres a major effort in additional validation of 
site data yhich is often incomplete of inconsistent. 



Site Data 

Colflection of data has- proven to be a problei^ because 
of- differences that exist among sites with respect to 
data that are routinely collected, tilassif ication of 
services, classification of resources, costing con- 
. ventions, etc. - = 

• Collection of data was accomplished with two question-^ 
.naires: the first one was unstructured to gain a * 

_ better overall understanding of each site, andf the^ • 

^ ^"eirniid one was structured according to model require- 

' ments (particularly with respect to curpent service . 

• ' ' type supply and demand) . * ^ - 

• ^Benchmark programs have been run and are available to 
* ^ ' verify ^ata acrosi sites* 

• Initial data are aya'ilable on all 16 sites and steps 
are being tak^n to collect missing <iata and resolve 

_ inconsistencies. ' * v 

Data from seven *site^ are contsidexed complete enough . 
for valid prelimin%ry network studies^ * . \ 

C. Status and Implementation of Background S-^dies 

^1. j S^jvice Typeafand Workload Representation - Mo%t of the 
background -studies have beejf clompJLet5d' and the results have been 
incorporated into the model. For these, -the ^resultant model char- 
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.^ctfer'xstics are described. For studies st yJ. i n prcigr^^s-, the 

current status is presented. • • • • . 

/ . . ' ' ' ^ , r - ■ 

. _ , ./ ♦ . ; • » 

^ ^. - • "Service types" are used to cKaracterize relatively 

homogeneous (with respect to machine impact) computing* 

services. , , i - . 

• . • Dimensions considered include batch versus interactive 
/ . : "iobs, type o£ resources required (e^g^, CPU or input/ 
output), size of job, and priority* ' , ^ 

It i s - 'des irable to keep^the numl^er of service.* types^ ■ 
below 50, ^since this number i^ the major determinant 
o£ the primary memory requirement for the modelC ^It. ' 
also represents an upper (perjbaps too high) limit on 
-the level of detail at which sites are 'able to describe 
current activities. ' \" 

Representation c^yrrently .consists (ff ^48 service types: 
ll. in.teractive with priority 1, 1 fast batch with 
pijaority 2, 5Z g.eneral batch with priorities 3 to 
6/ and 4 avail-able for unique services*"^ 



Demand in terms of each service type is mapped into 
resource requirements at each site«« 

t Seven resource types are use4> with f site dependent 
■ eighth resource type permitted* 

2. Network Organization and Administration 

^» . 

^ • A variety of alternative network organizational and 
administrative' structures have been defined* 

# Any combination of these structures can be represented 
by/ proper ^ecification of existing model parameters^ 

m Policy variation encompassing a wide range of alterna-^ 
tives is permitted^ ' • 

3. _ User Services and Support 

Level of service is expressed in . terms of dollars 
^ ;expended» 

# Budget for us^r, services at a giyjsn site is allt)cated 
across each service type. A variety of allocation, 
schemes is permitted* \ 

% Demand for a service ty^e depends (jLn additddn to 

pric^ ana turnaround) on expenditures for user support 
of that^ service type^ 
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• Cost" of user services includes both fixed and v&rial?le^ 
cost$. * ' . ' 



Communications - ^ ^ 

. : , 4 

C . ; ... 

> "Representation is capably of accojiimodating a wide 
variety of technplogies and prjLce strqc^ures- 

# Model currently utilizes communication technology 
and prices as provided by commercial organizations 

V su^h as Telenet. ; ' 

• The cost of communications include^ an initial inter- 
face cost, which is dependent onyr/^e of interface 
(e.g. modify host operating syst^g^s^ersus dial- in 
public port>. _ 

• Costs include^ a fixed pe^riod charge, which depends 
• on bandwidth and distance to nearest entry node, / 

a variable packet charge. .j^^ 

C6mput^eT Systems Performance Modeling ; 

♦ This has been one of the most difficult technical 
problems faced in developing -the^model, 

i Problems stemmed from heterogeneity pf hardware af 
the. diff^tent sites. 

# Current\approach taken (in Quefstionniire #2) is to 
ask each site for volume and performance data by 
standard service types and *to utilize this data 
directly in simple tabuPar form. 

• A parallel study has b^en made to apg;ly aetwork queueing 
. models .to the performance measurement problem in an 

'attempt to obtain analytical representations.^ Early 
results are very encouragiifg. 



Supply Detertainatibn 

S ^ ' ' ' ' . " 

• An institution's supply policies' pertain to budget 
hardware, software,, service offerings", suppor-t 
services, and prices. . ' 




• .Level for each element of supply (e.g. , hardware) is 
governed, by the budgeted funds allocated to that 
element, the actual or perceived demands^ for it, 
and site policy decisions. ; - 



130-" 



/ 



/ 



'V: 




7^ - Demand Estimations 



• Demand -at a given site is initially estiitfated by 
user category as^^ functidn of past ysage, growth 
trends, ^seasonal effects,, turnafround,. price, and 

— --^ser supports 

• Aggregate demand at, a site by tiser category is ^en 
mapped into demand by individual* service type. 

• Service type demand at*^ a user /site is then al located 
among competing supplying sit6s based on price, 

. turnaround, user gupport, and/ inertia (i.e., reluctance 
or inability of users to make/ rapid shifts in th^ir 
demand among sites). 



8» Pricing 



Sites can set prices for each* service^ype directly/ , ^ 

• Most sites prefer to se-t prilces for raw^ resgiyrces and 
let the model calculate service type prit^s/^ 

"V Typical of the*pricing strategies available to supplier' 
sites is that of raising prices of heavily utilized 
resources and lowering thosj^ of und«^- utilized ones - 
thus encouraging more effidient overall system utili- 
zation. I / 



9. Site Representations 



c 



ERIC; 



Capacity at a sitd-ir^defined in^c^rms of^he maxi- 
mum usable capacity of critical resources^ 

Each available service type at' a site is defined in 
terms of its requirements for these critical resources. 

Communication capacities, reliability^ estimates , and - 
scheduled availability are also collected by site.- \ 

Each site presen-ts a unique set.of^rom oneVto ten 
user categories .(e.g.-, administrat(irs> stuffs, 
researchers, etc.), from which demand by^^rvice ' 
■type i,s-g«nerated. . 

Policy •variai>les /for each site define its demand . 
policies, supply" policies, and "market!' policies 
(i.e., how capa^city is rationed if all of t^he demand 
cannot be satisfied) . 



r 
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• Other site-specific data pertain to .such inatters as 
pride discounts for specific buyers and iion- standard 
communication cos±s t(^ specific sites. 





Phase r Simulation Experiments ■ ^ - * ^ *^ 

• r- Emphasis was on exercising and validating the basic 
. simulation 'model, / - ' ' 

:^prehen5i;ire set^ of experiments was designed- in 
detail* These included explorations. o'f sucn areas 

^ , : ■ ■• 

■ V . ... . 

- Bilateral agreements versus central network - 
organisation.- ■ -' ■ • , 

I » ' _ 

^ Site 'Specialisation - . ' 

Pricing levels 

\ Propensity of users to shift sit^s in response \ ' 
\. tt> lower prices or Ijetter service 

- Effects of quality of networlc information diss.emi- 
:/ nated to users on network usage *' . i 

^/^ t' . ' ' ^ ^ ' ' 

- . - Communication costs \ ' ^ 

Identif icati'bn of, constraints pn rejsourize Sharing 
J? ' ^ ' ' 

- Dynamic network behavior when major p^turbatlons 
were introduced . ^ ' 

. - Consequences of alternative network structures . 
, / and .arrangements on: - ' , ' 

Supply. %nd demand at each site . ; / 

^ I'' ^ Ifor^ $ldw/ patterns , / * ' 

balance o^ payment patterns . ^ , 
Growth patterns ^ 
Equilibrium- conditions ^- • ' 

' f The^mfodel is capable of examining all of - the* situa- 

tions^^'listed abo:^e» - . ' 



^ V Se^Feral of the eiJcpeJrimenis yhich did no.t require Phase 
\11 policy inf ormation or a full set of^ validkted site 



/ representations were^-^conducted. ' 

• ■^Many of the rem'aining experiments will be conducted*, 
during Phase II as site .data and poiicy repre^elntations 
permit, v. ^ ; . - . ^ , . ^' 

r- * 13S .... , ■ ■ ^• 
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- B/; Perspective Relative to Worlcin Phases II and III 



■a. 



Not all basic Phase I site data are available. The 
-rest will have to be collected and; validated in- 
parallel wtih Phase II. ' . ^ ' ^ \* ' 

# Phase II data callection will* include both written i 
/ ♦ questionnaires and on-^ite interviews. Focus will 
pe on instittPeSronal policy and decision malcing be- 
,.'havior". • . , ' . . ' • 

j$ The current model is fully adaptable to site-specific 
policy and behavioral data. 

^ J. 

0 Phase II. will use. the model to represent the actual 
policies arfd- decisions of the participating institu- 
tions. ' - ' 



% Phase II experime^jS^^ill examinie'the implications 
. tff-^ variety of^ site ^nd network policies and decisipns/ 
on network floiSrs, ^individual netwdrk memhers, and 
overall networkSifability. 

Addption of the model to allow interactive 'gaming 
decisions in Phase JII should be les5^-dif f icult than 
expected. ' ' 




Phase I^I will allow interactiv^^election and: rao^- 
fication^ of policies by institutio*al representatives 
in order to explor-e the dynamic aspects of network 
behavior* ' . . ' * ^ 
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T^^ajor segments of the model are discussed in? detail in 

this appendix. As descril^ed in Section III, the modei design is 

based on a modified top- dcjwn, structured prograsnaihg approach. 

This ^fsciissi^n^figilows the seqUence specified by th^l%ystem 

flowcharts which appear as Figure A.I-la - A»I-lq fallowing the^ 

text. The flow .of control in all cases is from top to bottom, 

♦ 

left to right. Looping is indicated by cross rhatching ^s, for 
example^ in Module 3,0 of Figure A,- 1- la.. Jhe Symbol ¥^ is read: 




Module NEXSIM is the main program axtd^ serves to control the 
entire Netwo^ Simulation Model . * All -pins are initiated by calling 
,this module. It, infcturn, calls other modules as required. NETSIM 
performs three ma joy functions: ^ * 

1, "Common variables are initialized to zero.. 

2. Input/Output unit ttui^bers are set. 

3^ The five jtop- level functiona^^^X^utines are called in the 
sequence indicated in. Figure A. I -la. 

Figure A. I-la""suiamarizes overall aodel^operation, as wejLl zs^ 
;illustrating the modular approach to the model design^ Note thax 
the user only interfaces with one module/ NETSIM ♦ NETSIM, in turn, 
does some preliminary initialization*. Its major fimction,^ however, 
.is tot divide the task <5f running the overall simulation into five 
^ogical components (sub-modules) and then to control the use of 
these modules* During this process some modules may be used more 
than^'once, as indicated by the looping in module 3.0. In general 
each of the subroutines called will, in fact, be the primary roii- 
tine for a similar hierarchy. This process continues with finer 
and finer definition of function's- until all computation ne/eds 
havfe been satisfied.' ^ 
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This module (Figure A* I -lb) controls all data input. , There 
are 1:lire^ laain categories o£ input data: 

it* IRNQTMl.l) - Run Control Input Data - Interactive data 
are read in jao^ule INTAC, and includes such itess as the niiiaber 
of weelfs to fee simulated^, ^he'^date of the run, the type of run* 
(restart or original) and any run time c<iHBients,' If a resta-rt 
is specified;^ ^ddule IRLGIN will read the required restart, data* 
f roa .the Appropriate fiies.^ , 

2. INETWK(1>2) - global Parasfeters - Defined as parameters 
that are not specified to any one site, global paraaeters include 
systea parameters (Module ISySPR)/such as the nuaber of sites and 
service types on the network; and network paraaeters (Module INETPR) 
such as network coianunicatiohs costs. » This input section is^by- 
passed' in case^ of a restart. 

■ 4, ■ 

•3. ISIDAT(1.3) - Site Specific Data - The data /or, each site- 
are read -in -the following sequeace: . 

a. General Site Data - Includes data such as* overall 
policy >rnf orm^tion, report selection indicators, 
number of scheduled up hours^' and r^iabil^ty 6sti- 
mates , . . ^ 

^ b* Site Supply Data Initial descriptions of budgets, 
system h^rdware/sof tware, '^.ervices offered, prices*, 
r . user support, and capacity impact factors* 

c. Site Desland Data - Includes data such as initial 
base levels of demand for each user category, user 
category sensitivity and seasonality factors, and ^ 
mapping factors for determining service demand by 
/ user category. • 
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C« . ZSgTtJP.C2>0') - Run Initialization \^ . '. 

* . This fflodule (Figute A. I -Ic) performs all pre-run Calculations, 
policy initialization, and initial i&eport generation. The three- 
,aain Sections, q£/ZSETU^ are as follows: 

1. ZPRERNg2.1) - 4>repafl'--€&gputations - These include con- 



-fersidn of raw 6£bfa itt'^0 ^propriate forms, determination' df 
Smoothing -constants 'a^/i.nitial smoothed 'values, and a variety 
. of preliminary analyses. For "restart" runSj'-Siis module is 
bypassed. The major functions of ZPRERN are:-; 



ac. Initialization of the demand matrix, DR, and the' 
price matrix, PRICE, for every site and service' 
, . type. Other calculatJ.ons in ZCOMP include the^ 

scaling of input hourly system resource capacities 
to weekly figures and the. ops^mtation 'of initial 
resource utilizations at every, si-te. ' . 

the computation of initial turnarounds and respoiise 
times for every site and sei^ice type in-T^odule 
ZTl/RN. . , ' ' ^ ^ ' ^ 

C' The calculation of netwark average turnaround, price, 
and support is performed in' special analysis routines 
• . ANTCAL ■and'ANE3gfL, which are tailed from ZPRERN. 

. 5. ZIPOL(2.2) - Initialize Standard Policy Vector r See Ap- 
pendix II-B. " 

3. ZOUT(2>5} ' .Pre-run Output - Controls the outgut of initial 
information reports for the network ^5 a whol^ (Mpduli/^NOUT) and \. 
each individual site '(Module ZSOUT) • Initial reportj are xised 
for verification of pre-run conditions and as a res^gfinse point for ^ 
future comp^isdns. ^ 
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■ . . . - , . ■ • . 

D^* : .PROCESC3>0^ ' Proces^s^^^d Report * , t ' 

This is the controlling module for the period by period 
(weekly) processing and reporting'. Each time period (Figure A*I-ld) 
it successively calls routines for computation of exogenous changes, 
supply, 4emand, load balancing (market analysis), period analyses, 
2Cnd period reports. These routines fcixm the major part of the^ * 
simulation model artd are detailed in 'the following six sections.^ 



, E.. X0ijEN(3,l^ ' Exogenous Changes _ * ^ 

Exogenous changes are defined as those changes that cannot 
normally^be accomplished by the analytical routines in^iater 
Jjaodules. On the network ^level they, might inclu de ^ xi^ perturbations 
as new sites, entir^ sit4s going .off the ne^ii^ork for a period- of 
time, changes in network communicatioirxosts, or changes m orgain- 
zatipnal structure. At the site level, policy changes, configura- 
tion-changes, or revised demand profile^ all fit this category. * 

Only the (iverail module structure shown in Figure A,I-le has 
been implemented during Phase I of the pro'ject* Major use of the 
module has been for experiments that, require uniisual perturbations 
during the run. In general, special routiii^s must be written for 
this purpose each time this is done. During the later gaming 
phases of the project, XOGEN will become an interactive routine 
for on-line input of decisions and policy changes. 

F. SUPLY(3,2) - Supply ^ ^ 

The' output of module, SUPLY consists of descriptions, of those 
aspects of a site's offerings that are visible to potential users 
of the site^s computation facilities. These include available 
services^ prices, and levels of support. Such offerings are deter- 
©ined in this mpdule within the guidelines and constraints of 
supply policies, budgets, and available system^hardware and sctft- 
ware.^ Module SUPLY begins with an interpretation bi oyer^ll site 
' supply policies (3.21) and an evaluation of available' budgets and 
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budget constraints C3^22)*- The other determinations are then^. 
coB^leted in the, sequence indicated by Figure A^I-lf. ^The 
following sections detail this process. 

1. ^ SPQLC(3,21) - Interpret Overall Site Policies - This 
section of the model interprets the supply policy time fla^ and 
translates the current overall policy 'vector into specif ic^. supply 
areas/ Th6 supply policy time flag (Appendix II-G)^ indicates the 
Wtatxxs of the cuytent overall policy vector. A site may j^sAfttain 

the policies that it has >een using, try new ones for. a specified 
period^of time, or permanently change its "standard" policies. 
The first step in the interpretation of site supply policies is 
therefore the implementation of any changes in policy specifica- 
tion necessitated by the supply policy time flag* As an example, 
suppose "that XYZ has been following policies that give it a "c^s't 
cbnscioi^" profile • By using the "time flag" vector. It can speci 
fy that it wishes to try out. a "marketing" oriented profile f,or 
thirteen weeks (for example, during the glow summer quarter) 
A^ter this time'period, XYS's standard cost conscious policies 
will be reinstated. If later the site decides that the marketing 
oriented policies are preferred, these can become XY^'s standard 
policies. ' ' ^ 

' ■ ^ . ' * ' , - 

The second major step is to translate the overall supply 
p.Olicy into specific policy sets* This includes policy sets f.or 
btidget(ISPOLl), hardware/software (ISPOiZ), services available 
(iSP^tS),, prici^ng (ISP0L4), and support (ISPOLS) . As with most 
decision points^, a site can use general policy sets which have 
been j^ncorporated into the* model, ox it can access its own rou- 
tines. Continuing the example, suppose that XYZ is. currently 
fMlowing a marketing oriepted overall profile. .Its policy sets 
for budget;, hardware/software, services available, pricing, and 
support will all be compatible. with this profile* ' \ 

2. SBIJDG(5.22D - Budget - Tfais', and'all remaining supply 
modules ^ operate in, two basic* steps evaluation of the appro- 
priate nplicy set, and implementation of that set. The btidget 
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policy (ISPOLl) specified in module SPOLC is evaluated in SBGP.OL 
.in.oxdter ""to select the actual budget alg%titliins» and associated 
parameter^ to be -used in the implementation o£ this policy. If. 
the budget policy had befen specified in the Exogenous Changes 
mqduie (3.1) , SBGPOL would ,be b^pas'sed. . ^| 

. / , ' - ; ' ■ ■. ' 

' , second step in the process, is the actual computation 

the budget allowances accoxjijing to the' s'pecified budget policy in 
SBGIMP. Suppose, for example, that vector ISPOLl -implied that 
total budg;^^ jnay not>e-^anged, but individual items could be 
reallocat^' ^TTiisTmodule might then determine that the budgeted 
allowance Yox one of the user, categories was exceeded by actual - 
expenditures^but that other ca.tegories w^ere well below budget. 
Following thi seleoted policy, the. budget allowance for that user 
category would be increased, and ojLher categories would he reduced 
proportioi^tely . ' j * - 

3. SHDSF(5.25) - Hardware/Software - The hardware/software 
policy (ISP0L2X is evaluated in SHSPOL to determine the configurar 
tion change algorithms and their associated paramjeters/ If a site 
has specified its hardware/software policy in 'the Exj:>genous Changed 
module, this procedure would be omitted. ' 



Sjj^.tem utilization is then evaluated and' 'hardware/software 
capa^ty modified according to the appropriate hardware/software 
policy. 



- 4. SERVL(5.24) - Services Available - The availa1)le policy 
set tISP0L3) is evaluated in SRVPOL to choose-' th? attuai services 
availa^fet policy and the associated parameters * If^ site has 
specified its services available policy in the Exogenous Changed 
module, this section woujd he bypassed^^. ' 

The actual evaluation of the demandTfor the service types _ 
not currentlyof fered by the site takes place in SRVIMP-/ Factors 
whidh.^e considered a^e: the amount, of actual demand for the 
^service type, the turnarounds , response times, Vnd possibly the 



amount of unsatisfied demand for that .service type. If the site 
"decides" 'to offer a new service type, it usually incurs an^initial 
c^ost of introduction, for which there must be budgeted .funds . " ' 

5,, SPRlCE(3.25j Pricing - Institutions may handle pricing, 
in 4iffeTent ways. Rather than price by service type, most sites . . 
charge. for each specific resource. Fqr example, XYZ may choose 
to change it^-^^^irice for CPU time, thus affecting the prices of 
all^ services consuming CPU time'^in proportion to usage of this 
resour<;e. Assume, however, that a site decides, to i^ice by serv-~- 
ice_type. It may pick a policy which raises prices for services 
that need to be discouraged (according .to the same criteria) and 
lowers them for new" offerings or services where usage is .$0 be. 
encouraged." 

Unlike the previous service independent supply modules, sep** 
arate price calculations must be made for each service type* Module 
SPRPOL determines the pricing p'olicy and associated parameters 
based on ISP0L4. SPRIMP rapiemnts that policy and calculates the 
price 'of each service type* , ♦ 

6r "SUP0RC5,26) ' Support - This section of the model evaluates 
the support policy set (ISP0L5) fot each service type and then 
computes ^the actual levels of support that would exist under t/tie 
selected ^policies. 

* • 

Gi- DMA2rt)(5.5) - Demand " . . 

Thp DEMAND section (Figure A.I-lg) of the Network Siiflulatipn 
model controls the calculation of demand for .computer services and 
its allocation jamong available suppaiers (including the originating 
si,te) . ' ■ ■■ ■ ' , , . 

1, DP0ic(3.51> - Interpret Overall. ^ite Policy This module] 
translates tS^ overall site policies (lOPOLC) into specific poli- 
cies for' each user category for demand allocation (lAPOL) , trunca- 
tion, (ITRPOL - imposing -budget limits)^ and user category demand 

f . ' . ■ . • . 



allocation (lUCPOL).. 



~^-<:' 2. DETER1C3.-S2j - Determine gemaudr^Level - This module deter 
mines the dp^ired demand by us.er categorV by first cojuputing an 



, expected base 'level of demand and then? modifying tH^s level iiy , 
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seasonality factors and budget liiijitations^, ' > * 

a. DBASEC3^521) -."Bet ermine ^>a^se Levels The base' level 
^f demand (Jtigure AM-llL^ for- each user category is 
estimated first 21s 'a* function of tlie initial level - 
of demand and an assvuned growth profile. This^ini- 
tial estimate is th^n* adjusted to accommodate the 
realities of present turnaround, price, -and support 
ahd the effect /f these items on demand. -The ^ 
base ^level of/'demand for each user category is a 
dimehsionle^s number representing the amount (rela- 
tive to Levels at time zero) of ,overall deisiand. 
It wiri^later be translated^into service specific 
(fe^alid units. The process of 'determining the base 
' ^ level each period involves, the following -eqtiation: 

_ ' BU) = f (I^,G,T,P,S) ^ 

wjiere: I = initial base level of demand' 
' / .(at time « 0) ' 

G = growth^ factor for "base level 

i • T =jturnarbund (previous time period) 

" * , P = priee (pi;evious, time period) j 

• . • . S ^ sup^rt (previous time period) 

» • 
The effect <f the groifth factor is computed as a function of 

time; i.e., the week number. The effect of turnaround, ^price, and 

support are determined by the relative sensitivity of the -user 

category to each of these factors and the historically' expected 

values of each. 

- ♦ * . • if - 

■ ' < . • ■ ' • 

i. DGROWC3.3211) - De mandyBase Growth - This function 
* estimates the growth in demand based on some pre- 
determined algorithm* Typical algorithms might 



include expMfentialV linear, the results of a^e- * 
gression analyses tabular, etc* Presently it Is 
assumed tfiat all. demand grows .at a compound alumal 
rate of/R, where R is input for each us^r category * 
at eapn site^. * , 

/ ■ ♦ - 

BTlmN(3>3212) - Effect of Xtimaround on Demand - 

his function ^calculates an adjustmelit to the:^hase' 
level of demand based on turnaround* The .actual 
turnaround is conjpared to the historically, achieved 
turnaround. If actual is worse than expepted^ then 
this causes a reductio^n in demand ♦ , If the actual - 
turnaround is better^ than the expected turnaround, 
demand will be increased. The absolute magnitude 
of this change in demand level depends on the 
difference between actual and expecte4 and the ' 
sensitivity of the user category to this factor. 

< ' ' . 

, DPRICEC5.3213) ■ Effect of Price on/ Demand - This 

function calculates an adjustmenf ^to the base level 

of demand based on price. As in turnaround, the 

actual price is compared to the expetted "value and' 

the increase or neductiort is determined by the* 

difference and the user's sensitivity to price.. 

DSUPP(3.3214) r Ef fect> of Suppprt on Demand - This ^ 
function calculates the adjustment- to demand based 
on" support. Again, actual support is compared to 
^expected levels for determfning^ the difference and 
the e^fect^ ^ • 

DSEASCS.SZ?) - Seasonalize Demand - TMs module pexz 
forms the seasonalization.of .the base levels of demand 
for each user ^ategory . This is accomplished by multi 
plying the computed bajse level of demand "by a monthly 
Seasonality factor (assuming, a 13 month "year, 4 weejcs 



/ : ; ^ per in6nth) , i.e., by the expected percentage varie-- 

\ ^ tion. The seasonality factors are stored, in tabular 

. ^ form for each user category a.t each site. ^ 

* c. DTRUNCC3. 323). '/Truncate Demanxi (|ue to Budget 

. . ' Limitatighs The follpVing general procedure is ^ 

.'-^ osed to ensure tha^ calculated, demand is compati- 
ble with the. available budget: , ^ ^ 



i.t Spread (map) base leVel of 4^emand by liser catego^ 
^^1^1^ setvicp. type demands. A system uti^ty .routine 
"^Brrms this computation (UiJTMAP) . ' B^asically^, it is 
as§umed thaf for each user category, pro^of'tianal 
psage^'bf each service type remains constant Hence 
yreraji is -a simple proportionsjte mapping. 




Find the "Approximate cost to run these lobs using 
/ culft'ent prices.', 

iil. "Ada costs over all service types to ^et the expected 
• t^t&l expenditure for the user category^ 

iv. Use a budget truncation policy (Appendix II.E-3) 
* to determine if budger cSnstraints will Ue violated ' 
and, if so, the demand estiurate should be reduced 
- (truncated) . ' ** 

3. DALL0(3,33) - Allocate 'Demand Among^ Candidate Sxtes - As^ 
"with all. policy areas * this is a two stage procedure. The alloca- 
tion policies are first evaluated in module -3 .331 . Baseji on "these 
policies, the available sites are examined and the demand is al-' 
located (module 3.332). This module is exercised for each user 
categoicy. 



m. DAPaL(5.551) - Evaluate Allocatg-Oji Policies - The 
first /^tep (Figur^^ A^I-lj) is to determine for the 
*^ given user' category the restrictions on where these 




sets are allowed to go to 
hesj>oliqies ,the user cptegory Iwel are 
evaluated in module DUPOL. 



satisfy their deraan^. 



Befare deraand\jcan be discussed at^ the service typ 
level, it is, necessary to^iiap tHe user category 
base level of deraknd (deteimined previou^l^ in 
module 3.32) into service ^ype demands. Module 
DMAP accomplisfte^- this vi^) the system utility 
routine USTMAP. Finally, module DSPOL permits tier 



definition o^ s6rvice-spedific allocation policiJ 
if theS^ aryC desired. Mo^t site^will use the^ same 
policy for ^all 'work attributed to- a given. user. 

- ■ " ' /' . • 

DlAfcl0(3.332) - Select aid Allocate by- Service Typg 
Once all allocation polijcies have been defined, the, 

actual site^ sele^^tions and-allo^cations must be ac^ 

* ^ / 

complish*^d (Figu^e A.l-llc). TKis involves simul- 
taneous consideration of the site selectionjjresfehods 
and tWfe user. category allocation^restrictic 
is controlled by module 3.3321. 



and 



< 



i. PRATE (3. 3 SH) - Compute Alloc ations ^f^Demand * The 
rating and selection model^llocates service specific 
demands td the best available .site for each user ^ ^ 
c^egbry. .This, is done i,n three steps:. 

BC0SETC3. 332111 ' Set Rating Coefficients ^^The ca^.^ 
efficients lised for the rating of available sites ^ 
(including in-house) ^re -determined by this module .\ 
There' aife, toefficients for price/* turnaround, 'support, 



andjnomentum. 



past demand. 




irUCRES(3.332121 - Inpos'e User Restrictions '"- The 
restrictions oh available sites for* demand alloca- 
tiorf a^'the seryi^ce type level arp imposed i^^this* 
module, f ^ ' >^ 



) 



4^ 
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DPOLl (3.33 213) - Rate Sites and Allocate iBeinand -^ The 
policies set' in module DSPOL /(3.33i33 , in conibina- 
tion~with. the coefficients fiom DCOSET, and user 
category restrictions f r:onv/I)UCRES , are' used in ihis 
Siodule, , Every available /ite is rated, and the de- V 
mand is 'allocated on' the 'service type level to the 
best sites. Limits, as to the number of allocatible 
sites are set as;a function 6f folicy. 



ii. PSMTH(3.3322) - The 'caldulation Vf the expected , values ' 

of -turnaround, price, andj support foW/the iiser category. 
This is- a,ccomp-W.^ed by first computing the actual * 
values for .each service type, sumMng these results to 
^obtain a -fcotaL figure, and then dividing this total by 
^ >* .the number' of services ^manded by the user category. 

(y^^^' PSDRC3.332 3) - Update Demand Matrix (PR) - The alloca- 
. fions -determined in module 3. 33213 are -added to the 

appropriate 'elements of the Demand -Requested (Dg) 
matrix. -Values of ^his matrix represent a running 
sum of all.demajid. .This matrix is complete only after 
.the entire demand section of the model (3.3) has-been 
^ completed. * , . • . 

'H. MARKET (3.4) - Market Analysis * ' 

^ This routine (Figure A.I-i;i) controls the allocation of each 
site's systejn resources among the requested deman4s~from all network 
and internal users . It takes into account supi^ly" constraints , , • 

scheduling priorities, conmuhicdtion loads,. ett.. There are three 
iihajoT segments: .' ' 

- ^ ^1 MALL0(3.41) - Supply Allocation -Xhe allocation of system 
resources .*at ey.eTy site^is performed (Figure 'A.l-am) 'as follows: 

■ ^ ' _ . • ' ^ 

, ' . ^' ' MSUM(3.4n) - Demand Summation - All sexyice demands 
• originating a^ that sit? and all service specific de- 



/ ^ 'mands ditected to the site are calculated in this 

' ^routine. These demands are. then, mapped into system 

. • ' *. resource r'etiuests using the special routine RIFMAP 

* ' , , (service type^-to, resource, mapping,) . ^ ' ' . , ^ ^ 

- • -'b. NPOLEV(3.412) - Policy^ Evaluation 



This routine' 



assigns the appropriate segmen:^;<if the site's overall. 
, ^policy, to its mapket'poi^iyt ISPOL. This is actually 
► , done in MOPOLC. Upon jdeteirmination of this^'policjr, 
-MPOL (Allocation of Supply. Policy) determines the 
appropriate market cutback algorithm and parameters. 

The routine MC0T (3.41221) is useU to compute any ^ 
over-utilizations of system reources and to set the 
percentages to cift service specific demands. 

c. MREAL(5.413) - Allocation of Supply - This routi 
Controls the actual .c&tbacks of seryiice specific de'- 
mand-. The-methfed qf demand cutting is a function. of 
policy and specific site constraiiits (performance 
^< contracts, etc.). (See Appendix/lI-F) . 

2. MLOAD(5.42) - Estimate Turnaround - Trhis. rowt-ine will' esti- 
mate service^ type turnarounds at ever% site /for the purpose of al- 
locating "network" demand. This module is/a stub at the" present time, 

since the network site has not yet been implemented. 

^ / . 

3. ^INETC3,45) - Allocate Netw ork Demand - This routine will 

' : / * 'J 

allocate network- demand to the .best available sites/ This, module is a> 
stub at{the present 'time, $ince the network site has not .been im- * 
plentea. . * 




I. jmALV(3>5) ' Period Analyses 

This routine CFigure A. I -In) controls the* period summarx analyses 
for the individiltl sites and for the netwprk. It is composed pf two 
major segments. The calculations done here are available for 



reporting ptoses in the report segment C4.0).o, <; / ^ 

1/ ASITE(3.S1) ' Sitft Analyses - The' controlling :5outijie for 
the per^d analyses performed by every site calls the ^ollowirig 
modules : * - * * * . ' 



a. ASUM(3.511) - General' Computations • Compute site ^ 
^ , averages, summations, and other summary data. For 
• example, it calculates the site average, pr^e over 
all service types for each site. 

« « 
b- ATUmjlX5.513) - Turnaround Calculation - Turnarounds 
for every site -and service type, are determined in this 
module/ Every site has its own uiuque turnaround 
calculations sequenced^as ^odfiles ATNSOl through" 
ATNS20 which are called by ATURNl as illustrated in 
Figure A. I-lo. - / 

c. - APUSCS.SIS) ' Support Lev*el - This routijie computes 
the per unit dollar lei^el of support' that users will / 
see. These sUpport levels msut be deter^ned for ' , 
every seij\^ice oifered .at the site. 

d. ASTAFJ(3.514) - Site^taffing - Currently a stub, 
this routine is available ^or future studies con- 

'cerning computer center staffing at any site. 

e. ACO?'m(3,515) - Site CommunicatioYis • 'Hie ""total^ ' 
communications fload (both, from the network and to 
the/netwofk) is calculated in this routine.' Tliis 

^ is summed over all services. Note that feork satis- ^ 
fied i^-house will not be included in the commu- 
nicatigpl load since this^ is not sent, out to the ^ 
network. 



/. 



*Si A1MEXI 3.5161 - Income/txpense - Conjfols the compu- 

tattons of l.ncomp and expenses fpf every site during 
^ the past perlpd," vYearly"^cash flow figures are up- . 
. . dated to"inciud<i the new figures. These calculatiojis 

, • ' _ ^' include internal income, external income* _other 

^incooe, "coB^uivication charges, supply expenses, and 
total user /expenditure^. 

2. ANETKK (5 , 521 tM^^j^^rY^- Analyses - Statistical analyses on 
the network lei^iC^i^ire controlled by this routine, the order of 'flow 
is • 

f ' ^ , ' ' • ^ 

a. AHTCALiS.SZl") - Network Ayerages - Network-stati|tics , 
including average service specific turnaround and 

» standard dasyiations' Ibout the average, smoothed 

turnarounds, and average network pricesV are calcu- 
. la^ed- in this module. Thele figures are\b^sed only 
• •=• on hetwofk- sites' offering- the particu-las service type .s- 
in question. \' 

b. AN£m(3'.522) - Network Expected Values - Smoothed 

. (expected) values for *turna^Srd.,!^ice , an^ supporK^ 

' are computed for every service typj^-ift^^is routine. \ 

*A Each smoothed v^lue is a function of the^'ti^rent 

/ week's statistics and the pr-evious smdothed v^i^es. 

■ c. ACe>lM2 (5^5251 - Network Communications— This routine is 
• / for anVi^ses of^ network communications loads. It: is.- , 

a stubt* at ^l^sent . ^ , - 

J. OPORTO. 61 - Report '-. , - ^ 

*This routine generates all period reports, (Figure A.I-lq). EVery 
•site has the option of specifying any of the following types of period 
j^reVorts and the intervals which they should be generated: 

1^ RSIT£(5.611 - site Reports - Site specific reports are 

■■ ■ • • - 156 ' ■ - • - , 

. -15- . • ■ 




generate'd unde?5 the cqiltrol of this module, these reports include 
finaiiciil regoris such as budget, cash flow, abd income/ expend!^ 
ture rep'orts; special reports such a? site turnaround, site utili- 
zation, and site policy reports; and service ^ecific reports 
such as turnaround and price by service type^at every site on the 

network. , 

— , ' ■ * 

,*2* RNETC5>62) - Network Reports - Reports on network flows 
are generated by this routine. These reports include communica- 
tions, cash flows ^ and other special reports. 

* COHPUT(4.0) ' Sumaary Computations 

After all processing is complete for each period, this i-outine 
perforas various analyses concerning th^ entire length of the 
simulation. Time series analysef^s and tabulatioit pf network con- 
figuration changes are examples of the types of computations that 
sSy'^be done. Both this module and the following one are conceptual 
repref eStations in the nodule flow, since these calcfUlations and 
reports will most likely be done off-line after tjx-e-^imulation run 
has completed. ' \ 

L. 6ENREP(5.0) - Generate Summary Reports 

This routine controls the generation of sumary reports for 
the entire'^imulation run. These reports fall into two categories: 

1, SuEoaary reports on individual' site behavior including 
reports on connauni cat ions, service, capacity utilization, and 
summaries of the reports produced by RSITE. 



ivlor 



2. Sumnary reports on network behavior patterns including 
siuamaries of the reports produced by RNET. As mentioned above, 
these reports will probably not be produced on-line but will be 
generated from the -LOG file. 
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Appendix II 
Model Policies and Representations 



A> Policies and Practic-es - Overview^ 

The jnodel was designed to_ be highly parameterized and 
^'palicy-drivenJl Any discussion o£ the moSel must therefore 
' emphasize descriptions of the way policies are incorporated 
into the model and ^sed' within the model. Every simulation • 
run hegitis with the input of appropriate policies, pratf^tices, , 
and/or management dec4.sions for each sil:e. «These policy selec- 
tions^control various decision points within the model so^at 
the ^actions taken will accurate^ly represent that site (or a 
viewpoint which that site iaipht wish to test). : 

The policy selections determine- many aspects o£ site and 
network activity: \ ^ 

- how a site han^^j^^^s budg^^t 

• when and to what^Rctent it ujakes changes in its 
. configuration ^ • ^ 

- which service types it is agoing to offer for any period - 
^ . • the prices to be charged for any resource and service 

type ^ ' • • ^ 

J- the level of user support it will provide for a given 
resource type * 

- the level of demand generated by^local users 

"~ ^ budget constraints on the demand which ft^ generates 

• allocations of available resources when the site is 
over-loaded (which sites get priority because of previous 
dealings or commitments, etc.j 



In general, • policies are conceptually dealt with from two ^ 
•levels: an overall site profile and supply, demand, and market 
(load leveling). The "overall ^ofile" is reflecteld by a con- 
sistant selection of supply, demand and market policies to reppe- 
sent an institution's posture relativj^to a network. A singly 
vector -(lOPOLC) is used to carry indications of - the major polfcies 
\ in each.arfia. Several vectors are used to house the second level 



.policies., -^siipply, demand and marlget^ Detailed descriptions 'of 
how each of these perspectives is implemented are given in Sed- 
tions B through F^of this Appendix- 




' The dis-cussionViri this- Appendix focus on the structure of 
policy representatiojris and the options available within the model. 
More specific information relative to pipgranimi.ng conventions and 
procedures fpr modifying the model appears Appendices III 
through V. • ^ , . V 



B . Overall Site Profiles - . • 

The overall profile of any. site is reflected by the policiejs 
selected in^ the ^reas of supply determination, demand generation 
and allocation, and load leveling (market). Sites can be repre- 
sented a^ being predominantly' cost conscious*,, profit oriented, * 
marketing oriented (many services offered with good supp^ort) , user 
sensitive, etc. The model provides for alterations of overall 
site p^rofll^s (policies) during the course* of the simulation. ' 
TherQ are. two "policy vecjtors used to store these overall pplicy^ 
representations^ ' ^ . , 

lOPOLC - the .current overall trial policy for a site/ 

ICOPOL - th^ standard overall policy for a site 

* ' * • • 

Each of these vectors contains the full set pf tolt>-leVel pplicy 

numbers',' associated* parameters , and tilme'^f lags (Appendix II-G), 

Current Policy Vector (lOPQLC) Pot each of the major 
policV^reas, a list of available decision rules is^ m^aint alned 
within the modei^ The current overall policy vector, lOpOLC^ con- 
taiW.-Mther the. numbers of appropriate* policies from these lists, 
6r indics^tidns to' use site specific routines or procedures. This 
Vector is specified for every site by the INPUT section Xmo4ule 2,0) 
of the model. At the present time, the initial policies aremain in . 
effect for the entire §imT^ation run. ' I^later .project phases, . 
cyrrent policies will be changeable on eitWr a 'tempbrary *or perma- 



•nent basis in' the •Oogenous Changes" module (3.1). The j^arrent 
overall site policyMrector is- o£ the form: 



. JOPOLCClsfTE,?)^ 



where: .ISITE = site number . . 

' \' ' *. I- ^, to. 15 

Cpntcents o£ the sector for permissible values of' I are: 

i 

Description ' . 

1 - Supply policy affectipig budget (code nuaber - see 

Appendix- II-G). 

2 Supply -policy affetting hardware/software. 

3 Supply policy affecting services available* 

4 ^ Supply policy affecting pricing. 

5 Supply policy affecting support and user services. 

6 • - Demand .policy affecting ciits in demand at *the user 

. category level due to budget restrictions. 

7 Demand policy affecting^ user restrictions on demand 

allocation, , ^ ' ^ ^ 

8 Demand ^policy affecting service specific demand 

allocation. . ^ 

• .9 Market policy (load levelilig). * ~~ 

10 Variable 1 • Available for us^ by any. policy. 

Currently used to indicate tlie number ^of outside 
^ sites to which a given site may allocate its demand. 

11 Variable 2 - Available for use by any policy. ^ * 

Currently used to indicate the maximum deficit 
permitted by a ^ite. / ^ 

12 / Variable 3 - Available for use by any policy. --^ 

Currently not used, * • ' " 

13. Time, flag for the supply policies (see Appendix II-6). 
14 Time flag for the demand policies. 
15'- Time ^f lag. for market policies. 

• 2. Standard Policy Vector (ICOPOL) - The Standard overall 
po-licy (ICOP0L) is the general^ profile descrilJing each site\s 
"no-rmal "^behavior. It is initialized for the current policy .to 
the INPUT data, and remains constant throughout the simulation- 



In Project Phase III, sites will have the option of specifying .. 
new policies in the "Exogenous Changes'* module. Maintaining.the 
vector ICO£OL, in effe"S, permits a site to try temporary policies 
during the simulation run u's^.ng the^IOPOLC vector as described in 
tfte previous section. The periods of^time during which th.e tempo- 
rary policies remain in effect are specified with time flags 
(described in Appendix fl-G) in thS "Exogenous Changes" module. When 
the specified time period has elapsed, the standard policies are 
restored. Supply, demand, and market policies each have separate 
"Cxme flags. Jhe standard overall site policy vector is of tJie form: 

ICOP0L(ISITE,I) ... ' - / - 

where: ISITE = site number . 

I = 1 to 12 ' , 

For each site the 12 values' of ICOPOL are eqiiivallent to the first 
12 values of lOPOLC (see above section). * 

t 

C. . General Supply Policies * . • 

Supply policies fdr determining the budget and hardware/soft- 
ware configuration must be specified for each' sjLte* These two 
supply policy categories' relate to the,.ovefall institution computer 
operation and are not , specific for 'individual service types. The 
vector used is of the form: 

IP0LS2(JSITE,J,I)^ • • 

where: J ISITf -/site number 

Apolicy type ^ * 

1 - budget policy 

2 - hardware/software policy. 

. - ' I = policy indi'bsftor 

^ 1 " policy number " . ^ 

/ 2 -.parameter fdr^that policy 

1^ Budget (J-l) - Sites ^will have a variety of options /of '| 
evaluating thei^^udgets (see^ SectioA IV-H) . The following typical * 
budget poliicles are currently implemented^ * • - 




fp^ed budget - The budget is not changed under any 
circtriastances; This* policy might be used by a sit^ 
vhose. budget is* determined on an annual basis by, » . » 

'Say, the state legislature,. \, . i 

b, ^ I£ Sctua.l expenditures exceed a segment 6£ 5 the ' 
budget, the budget is raised for that segment 'and - 
a segment in which t^e budgeted 'amount exceeds ^ctuaX' 
• " expenditures is reducpd. This can represent, for 

ecjample, a site with a fixed £otal budget but'^ flexi- 
bdlity to4 realXocate internal budget lines. Decisions 
can be based on actual, expenditures to date, projected 
expenditures far the year, etc^^ , - ' / 

Hardware/Software CJ-2) • Either. actual or projected usage, 
te*s resources "Are compared with the capacity of each re- . 
i^ order 'to deterniine if any configuration changes are 

te. The following hardware/software policies are typical: 

he system '^should be highly utijirzed i.e. ^ MP* 
gr^de the system*©nly when necessary.. The system ^ 
is likely to^ be down |radj5*d when appropriate, e.;g. , 
if c^r^ain^j^ources kfe very under-utilized, ^his 
policy represents *a site with a "^st conscious" 
profile, and equipment that is primarily on short 
term lease ox rental. * ^ « 



b. Prwj^ct usage dptxurlstically - system. upgraded when 
appropriate-, but rarely ^do^gr^dedf. This policy 
might\^ be used bj^ a site*^with a "growth dntensive"- 
" profile. . ' - ' ' I 



4V 



4 



The systeif ^^^upgrader^^with gj^at reluctance, and 
rarely downgif^ded. Budgetajy^constrain^ts are 
followed.' Policy is similar to "a" except thaf . 
equipment is purchased *on' a long- term l$as,e. 

• ■ -179 . , /■ . ■ 
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'Jv'^ SefVice-^pecijElc Supply Policies \ ^ ^ ^ : 

i^he^e policies >^raVe in tlie same. manner a?%the policies* 
. described'in tKe previous section, except ^ri- somfe cases they may . 

not be the. same for all servic^e -offerings at th'e site* Policies 
-must therefore, be provi4ed afl^fe service type level. Areas of ^ - 
concern 4|j.clude^ detemining ^ioh services tp. x>ff erf , prices, and 
levels .o'f support' for each seryfce type. The supply policy vector^ • =. :* 
for servi^e'-^petific. policies is:^,^ V' * - * " T 

' IPOLSl(ISITE,mPE,J,.lt . ' • ' 

' ^ where: ISITE = sitfe number ' ' ^ \ ^ ,/ 

•* „ * ■ 'KTYPE = sei?vico type, - " _ 

J ^ policy t.^e\ . • . ^ — ^ ' ' . > 

s . . * 1 servicfs^available policy vector 

* ^ • * .2 = pr,ici^g* policy^vector . . 

. 3 =? level •of -support policy vector • % 

* I i« policy indicator - , . ' * ' \- 

' 1 - policy *set number 

• ' ' ' \ 2 - paramete^r .f^Sr" pplicy se^t . ' ^ 1 . 

1, Servjfes Available -(J^l) ^ It is asTsyiaed that^ there is an '>y 
initial cost for introducing each new service type. Currently it * ' 
is* assumed that this cost is ^he same for every si;fce. The pojiqy 
used njay vary wj.th the particular , service, type, e,g», file . 
manipulation and reporting must^ be offered, APL need not be.'' The ^ 
following policies for .determining servides, available are among*, 
the options- that^current'ly jnay be seCEeSted^^ . • * 

a^ , A new service type is qffered only .if there. is a 
' - • large unsatisfied demand for that service on the 

network and thexe is money 'available -in the ;apiiro- . . 
^riate fection 9£ the^budget. -'TMs- policy is" 
^y^callytased by a site with .a "cost conscious" " . 

• ^. , b*. *A new service ^type is offered i£ thefi is'a perceived . , 
- ' iongr term' demand for it (i.e., demand is- increasing) . 



-6-'- • - • ' ^ 



Budget cpngtraiivfs' ar.e disregatded. This policy 

.J- would be used by. a site with a "growth intensiye^*" 

* ' * * * _ ' * * \ 

^' profile. . • . . , 



t c* new serVLce type^iS pffered i£ there is an im- \ 

mediate demand for it. Bxidgetary constraints .are 
. ^ loosely fbllpwed,^but emphasis is dn cbmparing 
/ expected returns with costX This policy might 

' ^ * reflect a" site with a "m^afrketing oriented" prdfll^. 

,2* . dicing (J=2l - A numbed o^ different pricing policies \ 
are available in the 5todel. Most sites will pri'ce by resource ^ ' 
changing the ^"tiees for critical resources, undex- utilized jre- - 
sources, etc.'i ^o as' to encourage efficient pyerari system^usage. 
A change in the/resource charge will automatically affect the 
prices for 'all service t^e^ using that resource,, Note^ that a , 
site following a re source- based pricing s'trategy. will not have 
service- specific pricing policies. Some pricing poiicies^wi^h J^^ 
ifee theses ource charging alternjsitiye are: ' 

. - - . ' '•' -. - •• ■ ' . ■ 

a. The price of a resource is raised i^ it is over- - ^ 
utilized, and lowered if it is under-utiiized. 
Cutoff points for utilizations may be determined/ 
by specification of the parameter (I»2). 

b. Resource, prices are modified with t^e objective 
off matchii^ total estimated income "With, total 

Jtimated .ex^^Hitures.^ ^ , 

Other, sites may Arice dir^tly. by service offerig^, ignoring re-' 
sourcf? pharges.^^bis type of^olicy would. allow a site,' for 
example, to |>3^ the average price of 'a connect hour ot a fast* 
student compiler (i iJ^WAlJlV) . Some pricing policies^ yhfch *use 
rf^hVr the service-specific pricing .alternative or the resource 
charging ^alternative are : * ' 
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a. P;rices af^ raised^ 'abc^e the jie^orkv average if -sys- « 
tern utiXi2ation_is high and a/tual revenue is lower * 
Uthan pr^ectei- revenue. Prices .are lowered towards^ 
but above, the^network- average, if utill-zatijon ds^ 
' ^ low.r' ffhis policy is .t)rpically used by a site with. 
, ; . a "cost conscious^' profile. . ' ^ 

* b/ Prices .are raised" if utilizg^tion is high. Ptices 

ar? lowered if utilization is low., Thif policy is' ^ 

tised by a site with a "growth intensive" profile; 

• - » * - 

f * ' • . " * , ^ 

: ' c. Prices are raised •to network averagfe if utilization 

IS High and actual revenue is lower th^n projected 

revenue. Prices are lowejed- towa^s netwerk* average 

^ if utili^zation is lo*. \ This policy is used by a site 

with a "marketing oriented" profile. * ^ 

3, . Level of Support ^ Each site provides some level 

of support for each ^srervice type offered,. This represents the 
auxi^Mary Services* which may be available to the user of a site. 
At the present time^f^upport is represented as a sinjjle dollar 
level for each service type at the^-site (see Section 'IV-C.4). 
The.f o]/lowing policies for determination of support level are 
among those available i ' • " * ^ 



Try to stay ^lightly below the network a^^erage 
' whi^e closely following tht^ budget^. ^ *TiiiV poliby^ . 
is typically used by a si^&^-with *a "cost conscidu^'V-V^ 
profile. - ✓ • * 

b. Service-type dependent (i*e.., good support^ to some 
, -service types, and little o? no support •to othe&r ^ 
types). This policy may be used- by a site, with^a^ 
"growth intensive" profile to encourage approptiite''^^ 
service type usage. * . - • i 



c. Keep support levels above 'iietwork averages^ * Dis- - 
^ regard budgetary constraints'^- Th'is'.-poldcy iaij^t . 

'be used a siW-with^a "^i&e ting orient ed'i 
profile^ \ 



Note:| There are many aspects or^^pporvt to be considered. 



e.g., manual, prepara^on, printing-, online tutorials, CAI, and--- ^ 
advisemenV. These may: all be represented by the dollar costs* as 
4es<?ribed in each site"s budget." Fixed cosi^. ^ould include a^^/ 
visors' salaries, manual preparation,' etc., -while variable jrosts' 
.are associated with operations ^ch as printing manuals, phone 
calls, computer time used for support functions, e^c^ J The.gurrent- 
repres^nta'tion of support .in the site's budget combines the f ixed ^ 
and variable portions. Although, "quality of support" as perceived 
by th|_user. is obviously heavily iatif luenced 'by the tj^e of support 
prdvided;, it is reasonable to assume that, on balance, sites will 
provide- the most appropriate form of support for each service type 
User decisions (see Demand Policies - Appendix II-E) can therefore 
be based on the amount: of jaoney spent on the support function. 

E. Deiaand Policies - ^ 

% ; * 

1- User Category Budgert Constraints ,(IPOLDT) - This module 
Compares user categbry expenditures .with the budgeted amounts and^. 
if necessary, "truncates*' the demand estimation's© that it is* 
compatible with available funds. The major issue ^in this segment 
concenxs, the;, definition of "available funds." The policy vector 
for yie determination ef a sire's ^budget trxincati^n method is: 



I]^0LDT(ISITE,IUCAT,3 . 



1 



wher^e:, ISIXE = site number 

lUCAT = user category ' \ ^ - '* 
^ I.^ci or 2 , . ' . \ 

# 1 r Itudget truncation policy . 

2 truncation policy parameter 



Typical policies ^or Vietermining the cutofi paint are: 

a. Never allow a weekly expenditure to exceed *l/52 
- • annual budget. (This trivial policy 

used only for model tasting^. ^ ■ 

' ' ' r> ^ ^ . , / _ • ' ' ' : ' 

' b. Never allow the cuaulative expenditures .at the 
end of week ij to exce^ n/S2 ^^±mes the annual 
budget by laore than XI, wh^p X- is the parameter 
assq^:iated with this policy. 

. ' ■ - ' V- 

c» Do not allow cumulative expenditures to exceed 
n/S-2 tines the annual budget by sore than X% of 
the renaini^g^'fuhds i.6., XI of tises tlje 

•'/annual budget- wher^ X is as specff^^^ abo^. 




d. Place no jpsstrictions on expenditures. 



e7 ^Sajae as 11)" but. applied to all user categories / 

coiabined, ri.e*^_only total expenditures.* 

« A. * ^ 

V • * • ' ' ^ > , 

f . Sane as "c" byt applied to ail user categories - " 
conbiaed . 

2. User Catej^qry Allocation Restrictions (IPOLOA) - After 
\3the total deaand for each user category i^ detelrained, this demand ^ 
aust be allocated" to particular supplier' si^es, Soae user *^at<^-. 
^ories at the site may 5at 5e permitted to use the services offered 
•at certain other sites. £dr exaiaple, a student at ABC Universxty 
laSy not be able 'to send a^ work outside* A facull^ aeaber,'on, 
the other hand, aay be able to use sites XYZ, AAA, ^r ZZZ for bi^, 
wotk. . These restrictions laust be established before ^the workloa^^ 
can be distributed over the network. .^?nhe" policy vector ^ or t'he 
determination of a site's user category .restrictions* is: ; 



^ ^ ' IPOLUACISITE,IOCAT,I) ' 

' Inhere: ISI-TE = site number > 
.-^ lUCAT * xi^er category > 

^ . I f 1 or 2 . . 

' 1 - V^er category -policy jiuaber-"^ " 
; . ^ 2 parameter associated with the 

V ' user ^category policy 

3. Djepand Allocation - After budget •constraints bkve i^ff^c^^ 
deaand as required and the user category restrictions have b|ien ■ 
inposed, the demand aust be allocated among the avail^ble^^si^es.f" ^ 
For pxaaple,'one of^ XYZ University's user category pdllcies may . _ 
be, to limit all allocations to either itself or AB(>^In this* ^ 
case, the'Tieaand allocation jiolicies will be used to evaluate both 
sites and^ecide how much of the service typ^ demand to allocate 
td^ each site. The current method involves a rating algorithm by 
which the sites are ranked and demands allocated^ in proportion to 
their^ .rating . A variety of rating algorithms cpuld be hypothesizei. 
At present, the rating ^consists of a linear combination of price, 
iurn^rQUij4-l sus^rtt_and_paLSt demand C^Q6^ntuaX,_^e coefficient^ 
used in the rating equations for certain policies are sx%b specific, 
e.g., .a site can choose to look for good'pric^ and ttimarozind for 
one usear category, and support for another. A ;^site can assign a 
different coefficient to -each rating coi^onent for each user ^ 
category. The relative freights placed on the factors will deterf 
mine Where Ae ,deaand for that user is allocated. Hie policy ^ \- 
vector .for the determination of ,a site's, demand allocations is: 



IPOLDA(ISITE,mPE,I) : • y^: 

' where: iSITE = site nximber . ' ' - 

>^ XTYPE - service type ' / - - - ^ 

I « 1 of '2 ^ J . , 

1 - demand alTocat&on- policy Set number 

2 - parameter asso.cij^ed with the dejiaad- 

allocation pol^^ set • • • ' ' 



servic 



The available service specific demkisd allocatioji policies currently 
include: . *• ^. • • t . 
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a. Ldbk^for .the site offering 'the lowest prices. .This 
/ policy is use'd lA a site with a "cost'xonscious" 

I profile, or in te^s of overall deaan(i"~>^actiQes 

:- /?^rice accountability." — *- '-^^ 

b. Restrict network iisage. fry to stay in-hoiise as* 
' auch as possible. This policy is used' by a site 

with 'a "growth intensive" profile or with cofstraints 
outside expenditures . ' ' 



c. Look for the site offering .the best combijiatipn of 7 
turnaround and price. This policy jfright bemused by 
a site that is "useV sensitive^/' but still has price 
accotintability . - • . 



Market Policies ^ \ 

After all sites have allocated their demands for all ifeer ; 
categon^ iev^ls^nJ"aii service types, each^sTt^e'^st check the 
^easibi^Lity* of- running all df the -batch jobs, and' supplying all 
the requested connect ,tiae. • Factors to be cons ide^4^ include 
utilization of cocnaunications lines and oth^r critical resources. 
.Thte resource requireae.nts for the total- desand are calculated and 
coiapaTed'ta-the availabj.e capacajSy. If the capacity , for any rrit- 
icai resource is exceeded, *the' demand cannot be ^satisfied. If .¥> 
it is deterainfid tha^ a site canno't satisfy all deaand requested- 
f of. th^ week,, the appropriate "market (supply allocation) policy , 
sust be used to 4eten3ine what deai&nd/will- be satisfied and what 
' imsatisfied'. Soae laarket policies currently iaplea^nfted are: 

' 11 For each resource that is over-utilized, tha sTervice 

types are cut in proportion t6 their usage o£ *the over-: 
^ utilized resource* Cut all sites'equally ind^endent of 
their iis^ge (dovm to zero).^ ^ ^ ~ 

: . , Zy Cut back all work in proportion to Tlfe qver-ji€ilization 

• . independent -of service type i^e/, the job queue cannot ^ 



aetermine in advance* which. jobs to cut. The policy ' ' 

4 vector f oif the deterainatioii of a sit«/s market prac-: 

• * " ' . ■* • 

tices is: ^ ^> ' . . ^ • . * . ' 

/- * • . ' « , - • 

> ^ ' IPOLSA£ISITF,KTYPE,IX - ' ' , / * r! * \ 

--^ . where: . tSITE - silte number . ^ - ' ..y 

— ' ^ ' XTYPE « service tyfje ' ^ . . w . / ^ 

' . f ' I 1 or 2 ^ • . • . 

. ; '^^^ ' ^ • 1 • market policy sei lauaber - . 

i ^ '2 - parameter associated -with -the 'f^ 

. ? * mapket-p^licy set * '% . 

Policy Conventions * 

3t nuiabex>cf conventions rela^ye to Ijhe representations of \ ' 
poli<:ies have been incorporatjed int<j the Network Simulation Model, 
The tWo most important . ^^ descrih edbelow. concern the ntimbering of 
policies, and the time flags that p^rai't the lise o£ tempora^?^ of 
"trial" policies./ . ^^''^^ • * ' ^ 
. . ; ' % 

1, Overall Policy Conventions - TJie followxnV conventi?bns 
apply to polipy number's contained iW the over'iall policy vectoi? in 
the model: . * ^ 




olijby Number ^ , Meaning 

1. ^iesi -than 0 , / S^ite chooses to implement; a 
I ' ' " - unique policy,/ (i*e.y its 

' ^ own sub) 

2. % 0 ' . No change in* specific policy 
^ , . ^ (i.e.,*s£Lme policy as last 

• . .. - 3 ^ ^ ^^p^iod).; 

' ' greate"f rthan 0 ' Site, chooses ofle of the 

* * y - ^ « ' standard policies available 

• ' ' ^ in the -model. • Substitute ' 

^ this poliq^'ntaaber for' what- 
ever 'was used previously. 

2*^ Sjpcond Lfivel/Policy Cohveiitions' - When dealing with ^econd 

level; pqlicies> the conventions are as follows : * ^ 



-<0 - site spedtific algorithm -to be used f 
-0 • do nothing, i.e., no kction * 

;K)* the nximber of the standard algorithm" to be used 



3. r Time Flags - "Each pojicy Has an as^sociaXed time flag in - 
the ov^i^ll policy array, lOPpLC. Time flags ^re used so that a 
site may implemeiit a policy, other than its''6tan da/rd policy for any 
speci^ed temporary period -of ti&e. After this time has ela^sed^ 
the site*^ standard policy will' be. restored. The current 5^1ags in. 
use " in arjray lOPOLC are : . , . 



1. 



Time Flag 
-1 



3. positive ijitkg&t^in) 



4. 



999 



Meaning 

New standard policy - saVe 
and set time flag to 999. 

SpecJ.f ied time has elapsed - . 
restore standard policy aii^ 
set* time flag to 999.' 

• . • * * 
P61i<:y will jbe u?ed for n 
periods to follow, after 
which staitfiard polie/ will 
y be restored. (n is decreased 
by 1 each 'time period). ^ 

Policy is to- be used indef-* 
initely. tAny integer greater 
than the. number of time periods^ 
in the simulation run). . 




H.^ Representation of Budget and Cash Flow 



Budgerts are based on a yearly time interval , Starting at a 
specif ie4 ^^ek (#1). The, total bottom ,njies are' not changed during ^ 
the y^ar (except in the ."Exogenous Changes^* module) but the dollar 
^mounts allocated to the* v^'^^^us. categories cap be reallocated using 
'budget policies (practices) . - r * ' ' _ • " 

/ . • . ^ ' 

Acttiafl ca^iji flows are conf igu;r|d^ in the same fonA as the bixdget- 
representation. J^onthly or weekly: cash flows aFfe projected to ^ _ 
Cover a yearly period in order to examine iny discrepancies between 



budgeted .and actual ^oiult^s . The manner., of ^roj ectioa (i". e , ^ 
, 5traigfit ling this wjeek; 1752 aimual'; a functipn of total , 
; expenditures to date, weeks remaining, etc.) is a site-depindent 

function, of policy. Tjie vectors used fpr budget and cash flow 
' ire: ' ' ' . ■ ' ' ' * 

BUDGET(ISIT£,ICAT) • the yearly budget 

CHSFiO(ISIXE,ICAT) j the actikl tfash flows (cumulative 
' * : to date)\ * 

where: I SITE = site nuinl>^ \ , - 

y]^T ' ^ income expense] category . 



1/ — 




At, the present time, BUDGET § CHS^LO^have 25 "income/expense V 



categories each. These are as follows 



^TCAT 

^ 1. 
2 
3 
4 
5 

6 

-7 
8 

9 . 
10. 
11 
12 

■ir 

16 
17 
18 
19 

'2; 

* 22. 
23 
> 24 • 
/ 25 



CATEGORY , , ' . ^ . 

Total Income of computer center ' • ' 

Total expenses of computer center / 

Internally generated income using School funds , * 

Externally., generated income, .outside use 

Other computer ^eirter incom^^ (grant's,. contHbii- . 

tions, etc.)'^d/or deficit 
Hardwar^e/Software committed expense ' 
Funds available for improvement 
. User support' * ^ * 

Total user expenditures ' . ^ * 

Communications fi^xed expense . , . 

Communica^tions variable expense ^ . " 

Supplies expend, cards, paper tapes' 
Operations staff , \ ^ 

'/Programmiiig staff - ^ * * , " . 

.Administration expense ^ • , 

, Ufeer category I expense 

" " . * II expense^^ ^ • 

'Ill-expens^'- * 
^ IV expense 

V ^xpensa * ^ k 
^ VI. expense- - ' , \ 

" . Vli expense ' ' * 

" . . VIII 'expense , 

" IX expense. ^ ' 

Usee cat^ory^X expense 

*. 
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